* Re: [REGRESSION] sdhci no longer detects SD cards on LX2160A
From: Fabio Estevam @ 2019-09-17 13:56 UTC (permalink / raw)
To: Russell King - ARM Linux admin, Li Yang
Cc: dann frazier, linux-mmc, Adrian Hunter, Will Deacon, Nicolin Chen,
Christoph Hellwig, Linux ARM
In-Reply-To: <20190917135157.GT25745@shell.armlinux.org.uk>
[Adding Li Yang]
On Tue, Sep 17, 2019 at 10:52 AM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
> The pressing question seems to be this:
>
> Are the eSDHC on the LX2160A DMA coherent or are they not?
>
> Any chances of finding out internally what the true answer to that,
> rather than me poking about trying stuff experimentally? Having a
> definitive answer for a potentially data-corrupting change would
> be really good...
Li Yang,
Could you please help to confirm Russell's question?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [REGRESSION] sdhci no longer detects SD cards on LX2160A
From: Robin Murphy @ 2019-09-17 14:03 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: dann frazier, linux-mmc, Adrian Hunter, Will Deacon, Nicolin Chen,
Christoph Hellwig, Linux ARM
In-Reply-To: <20190917134947.GS25745@shell.armlinux.org.uk>
On 17/09/2019 14:49, Russell King - ARM Linux admin wrote:
> On Tue, Sep 17, 2019 at 02:38:00PM +0100, Robin Murphy wrote:
>> On 17/09/2019 14:07, Russell King - ARM Linux admin wrote:
>>> On Tue, Sep 17, 2019 at 01:33:26PM +0100, Russell King - ARM Linux admin wrote:
>>>> On Tue, Sep 17, 2019 at 12:42:10PM +0100, Russell King - ARM Linux admin wrote:
>>>>> On Tue, Sep 17, 2019 at 12:16:31PM +0100, Russell King - ARM Linux admin wrote:
>>>>>> On Tue, Sep 17, 2019 at 11:42:00AM +0100, Russell King - ARM Linux admin wrote:
>>>>>>> On Tue, Sep 17, 2019 at 09:19:31AM +0100, Russell King - ARM Linux admin wrote:
>>>>>>>> On Tue, Sep 17, 2019 at 10:06:12AM +0200, Marc Gonzalez wrote:
>>>>>>>>> On 16/09/2019 19:15, Russell King - ARM Linux admin wrote:
>>>>>>>>>
>>>>>>>>>> The platform has an iommu, which is in pass-through mode, via
>>>>>>>>>> arm_smmu.disable_bypass=0.
>>>>>>>>>
>>>>>>>>> Could be 954a03be033c7cef80ddc232e7cbdb17df735663
>>>>>>>>> "iommu/arm-smmu: Break insecure users by disabling bypass by default"
>>>>>>>>>
>>>>>>>>> Although it had already landed in v5.2
>>>>>>>>
>>>>>>>> It is not - and the two lines that you quoted above are sufficient
>>>>>>>> to negate that as a cause. (Please read the help for the option that
>>>>>>>> the commit referrs to.)
>>>>>>>>
>>>>>>>> In fact, with bypass disabled, the SoC fails due to other masters.
>>>>>>>> That's already been discussed privately between myself and Will
>>>>>>>> Deacon.
>>>>>>>>
>>>>>>>> arm_smmu.disable_bypass=0 re-enables bypass mode irrespective of
>>>>>>>> the default setting in the Kconfig.
>>>>>>>
>>>>>>> Adding some further debugging, and fixing the existing ADMA debugging
>>>>>>> shows:
>>>>>>>
>>>>>>> mmc0: ADMA error: 0x02000000
>>>>>>>
>>>>>>> So this is an ADMA error without the transfer having completed.
>>>>>>>
>>>>>>> mmc0: sdhci: Blk size: 0x00000008 | Blk cnt: 0x00000001
>>>>>>>
>>>>>>> The block size is 8, with one block.
>>>>>>>
>>>>>>> mmc0: sdhci: ADMA Err: 0x00000009 | ADMA Ptr: 0x000000236df1d20c
>>>>>>>
>>>>>>> The ADMA error is a descriptor error at address 0x000000236df1d20c.
>>>>>>> The descriptor table contains (including the following entry):
>>>>>>>
>>>>>>> mmc0: sdhci: 236df1d200: DMA 0x000000236d40e980, LEN 0x0008, Attr=0x23
>>>>>>> mmc0: sdhci: 236df1d20c: DMA 0x0000000000000000, LEN 0x0000, Attr=0x00
>>>>>>>
>>>>>>> The descriptor table contains one descriptor of 8 bytes, is marked
>>>>>>> as the last (END bit set) and is at DMA address 0x236df1d200. The
>>>>>>> following descriptor is empty, with VALID=0.
>>>>>>>
>>>>>>> One may be tempted to blame it on the following descriptor, but having
>>>>>>> had another example on eMMC while userspace was booting (rootfs on
>>>>>>> eMMC):
>>>>>>>
>>>>>>> mmc1: ADMA error: 0x02000000
>>>>>>> mmc1: sdhci: Blk size: 0x00000200 | Blk cnt: 0x00000099
>>>>>>> mmc1: sdhci: ADMA Err: 0x00000006 | ADMA Ptr: 0x000000236dbfa26c
>>>>>>> mmc1: sdhci: 236dbfa200: DMA 0x000000236c25c000, LEN 0x2000, Attr=0x21
>>>>>>> mmc1: sdhci: 236dbfa20c: DMA 0x000000236938c000, LEN 0x0000, Attr=0x21
>>>>>>> mmc1: sdhci: 236dbfa218: DMA 0x000000236939c000, LEN 0x5000, Attr=0x21
>>>>>>> mmc1: sdhci: 236dbfa224: DMA 0x0000002368545000, LEN 0x1000, Attr=0x21
>>>>>>> mmc1: sdhci: 236dbfa230: DMA 0x00000023684f1000, LEN 0x1000, Attr=0x21
>>>>>>> mmc1: sdhci: 236dbfa23c: DMA 0x0000002368504000, LEN 0x2000, Attr=0x21
>>>>>>> mmc1: sdhci: 236dbfa248: DMA 0x0000002368546000, LEN 0x2000, Attr=0x21
>>>>>>> mmc1: sdhci: 236dbfa254: DMA 0x00000023684f2000, LEN 0x2000, Attr=0x21
>>>>>>> mmc1: sdhci: 236dbfa260: DMA 0x0000002368500000, LEN 0x1000, Attr=0x23
>>>>>>> mmc1: sdhci: 236dbfa26c: DMA 0x000000236b55d000, LEN 0x1000, Attr=0x21
>>>>>>>
>>>>>>> ... which is interesting for several reasons:
>>>>>>> - The ADMA error register indicates a length mismatch error. The
>>>>>>> transfer was for 0x99 blocks of 0x200, which is 0x13200 bytes.
>>>>>>> Summing the ADMA lengths up to the last descriptor (length=0 is
>>>>>>> 0x10000 bytes) gives 0x20000 bytes. So the DMA table contains more
>>>>>>> bytes than the requested transfer.
>>>>>>>
>>>>>>> - The ADMA error register indicates ST_CADR, which is described as
>>>>>>> "This state is never set because do not generate ADMA error in this
>>>>>>> state."
>>>>>>>
>>>>>>> - The error descriptor is again after the descriptor with END=1, but
>>>>>>> this time has VALID=1.
>>>>>>>
>>>>>>> This _feels_ like a coherency issue, where the SDHCI engine is not
>>>>>>> correctly seeing the descriptor table, but then I would have expected
>>>>>>> userspace (which is basically debian stable) to fail to boot every
>>>>>>> time given that its rootfs is on eMMC.
>>>>>>>
>>>>>>> The other weird thing is if I wind the core MMC code back via:
>>>>>>>
>>>>>>> $ git diff -u 7559d612dff0..v5.3 drivers/mmc/core | patch -p1 -R
>>>>>>>
>>>>>>> and fix the lack of dma_max_pfn(), then SDHCI is more stable - not
>>>>>>> completely stable, but way better than plain v5.3. I don't see
>>>>>>> much in that diff which would be responsible for this - although it
>>>>>>> does seem that hch's DMA changes do make the problem more likely.
>>>>>>> (going from 1 in 3 boots with a problem to being not able to boot.)
>>>>>>>
>>>>>>> Note, with v5.2, I _never_ saw any ADMA errors, except if I disabled
>>>>>>> bypass mode on the IOMMU (but then I saw global smmu errors right
>>>>>>> from when the IOMMU had bypass disabled before MMC was probed - the
>>>>>>> reason being is the SoC is not currently setup to have the MMU
>>>>>>> bypass mode disabled.)
>>>>>>
>>>>>> This looks like an ARM64 coherency issue.
>>>>>>
>>>>>> I first tried adding a dma_wmb() to the end of sdhci_adma_table_pre(),
>>>>>> which had no effect. I then tried adding:
>>>>>>
>>>>>> + __dma_flush_area(host->adma_table, desc - host->adma_table);
>>>>>> + dma_wmb();
>>>>>>
>>>>>> and so far I haven't had any further ADMA errors. Adding Will Deacon
>>>>>> to the thread.
>>>>>
>>>>> These are the changes to sdhci that I'm currently running. I think
>>>>> some of the debugging related changes are probably worth adding to
>>>>> the driver, particularly printing the intmask on ADMA error (which
>>>>> is not printed by the register dump, as the value is lost) and printing
>>>>> the DMA addresses of the descriptor table entries which can be tied
>>>>> up with the DMA address error register. Also, maybe printing the
>>>>> DMA descriptor table with the register dump, rather than having to
>>>>> resort to enabling debug would be a good idea?
>>>>>
>>>>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>>>>> index a5dc5aae973e..884dcaa9cad5 100644
>>>>> --- a/drivers/mmc/host/sdhci.c
>>>>> +++ b/drivers/mmc/host/sdhci.c
>>>>> @@ -773,6 +773,8 @@ static void sdhci_adma_table_pre(struct sdhci_host *host,
>>>>> /* Add a terminating entry - nop, end, valid */
>>>>> __sdhci_adma_write_desc(host, &desc, 0, 0, ADMA2_NOP_END_VALID);
>>>>> }
>>>>> + __dma_flush_area(host->adma_table, desc - host->adma_table);
>>>>> + dma_wmb();
>>>>> }
>>>>> static void sdhci_adma_table_post(struct sdhci_host *host,
>>>>> @@ -2855,6 +2857,8 @@ static void sdhci_cmd_irq(struct sdhci_host *host, u32 intmask, u32 *intmask_p)
>>>>> static void sdhci_adma_show_error(struct sdhci_host *host)
>>>>> {
>>>>> void *desc = host->adma_table;
>>>>> + dma_addr_t dma = host->adma_addr;
>>>>> + bool end = false;
>>>>> sdhci_dumpregs(host);
>>>>> @@ -2862,21 +2866,26 @@ static void sdhci_adma_show_error(struct sdhci_host *host)
>>>>> struct sdhci_adma2_64_desc *dma_desc = desc;
>>>>> if (host->flags & SDHCI_USE_64_BIT_DMA)
>>>>> - DBG("%p: DMA 0x%08x%08x, LEN 0x%04x, Attr=0x%02x\n",
>>>>> - desc, le32_to_cpu(dma_desc->addr_hi),
>>>>> + SDHCI_DUMP("%08llx: DMA 0x%08x%08x, LEN 0x%04x, Attr=0x%02x\n",
>>>>> + (unsigned long long)dma,
>>>>> + le32_to_cpu(dma_desc->addr_hi),
>>>>> le32_to_cpu(dma_desc->addr_lo),
>>>>> le16_to_cpu(dma_desc->len),
>>>>> le16_to_cpu(dma_desc->cmd));
>>>>> else
>>>>> - DBG("%p: DMA 0x%08x, LEN 0x%04x, Attr=0x%02x\n",
>>>>> - desc, le32_to_cpu(dma_desc->addr_lo),
>>>>> + SDHCI_DUMP("%08llx: DMA 0x%08x, LEN 0x%04x, Attr=0x%02x\n",
>>>>> + (unsigned long long)dma,
>>>>> + le32_to_cpu(dma_desc->addr_lo),
>>>>> le16_to_cpu(dma_desc->len),
>>>>> le16_to_cpu(dma_desc->cmd));
>>>>> + if (end) break;
>>>>> +
>>>>> desc += host->desc_sz;
>>>>> + dma += host->desc_sz;
>>>>> if (dma_desc->cmd & cpu_to_le16(ADMA2_END))
>>>>> - break;
>>>>> + end = true;
>>>>> }
>>>>> }
>>>>> @@ -2949,7 +2958,7 @@ static void sdhci_data_irq(struct sdhci_host *host, u32 intmask)
>>>>> != MMC_BUS_TEST_R)
>>>>> host->data->error = -EILSEQ;
>>>>> else if (intmask & SDHCI_INT_ADMA_ERROR) {
>>>>> - pr_err("%s: ADMA error\n", mmc_hostname(host->mmc));
>>>>> + pr_err("%s: ADMA error: 0x%08x\n", mmc_hostname(host->mmc), intmask);
>>>>> sdhci_adma_show_error(host);
>>>>> host->data->error = -EIO;
>>>>> if (host->ops->adma_workaround)
>>>>
>>>> Further debug shows:
>>>>
>>>> coherent=0 - sdhci device is not cache coherent
>>>> swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000081cac000
>>>> [ffffff8010fd5200] pgd=000000237ffff003, pud=000000237ffff003,
>>>> pmd=000000237fffb003, pte=00e800236d62270f
>>>>
>>>> The mapping for the ADMA table seems to be using MAIR index 3, which is
>>>> MT_MEMORY_NC, so should be non-cacheable.
>>>>
>>>> vmallocinfo:
>>>> 0xffffff8010fd5000-0xffffff8010fd7000 8192 dma_direct_alloc+0x4c/0x54
>>>> user
>>>>
>>>> So this memory has been remapped. Could there be an alias that has
>>>> cache lines still in the cache for the physical address, and could we
>>>> be hitting those cache lines while accessing through a non-cacheable
>>>> mapping? (On 32-bit ARM, this is "unpredictable" and this problem
>>>> definitely _feels_ like it has unpredictable attributes!)
>>>>
>>>> Also, given that this memory is mapped NC, then surely
>>>> __dma_flush_area() should have no effect? However, it _does_ have the
>>>> effect of reliably solving the problem, which to me implies that there
>>>> _are_ cache lines in this NC mapping.
>>>
>>> Will suggested reverting bd2e75633c80 ("dma-contiguous: use fallback
>>> alloc_pages for single pages") which has been implicated in the same
>>> problem here:
>>>
>>> https://www.spinics.net/lists/arm-kernel/msg750623.html
>>>
>>> Although reverting the commit is not clean, this also fixes the issue
>>> for me.
>>
>> Note that that one turned out to be something totally different, namely that
>> the single-page allocations, in difference to CMA, came from physical
>> addresses that the controller needed additional configuration to be able to
>> access[1] - no amount of cache maintenance would affect that.
>
> As already replied, v4 mode is not documented as being available on
> the LX2160A - the bit in the control register is marked as "reserved".
> This is as expected as it is documented that it is using a v3.00 of
> the SDHCI standard, rather than v4.00.
>
> So, sorry, enabling "v4 mode" isn't a workaround in this scenario.
>
> Given that v4 mode is not mandatory, this shouldn't be a work-around.
>
> Given that it _does_ work some of the time with the table >4GB, then
> this is not an addressing limitation.
Yes, that's what "something totally different" usually means.
>> However, the other difference between getting a single page directly from
>> the page allocator vs. the CMA area is that accesses to the linear mapping
>> of the CMA area are probably pretty rare, whereas for the single-page case
>> it's much more likely that kernel tasks using adjacent pages could lead to
>> prefetching of the descriptor page's cacheable alias. That could certainly
>> explain how reverting that commit manages to hide an apparent coherency
>> issue.
>
> Right, so how do we fix this?
By describing the hardware correctly in the DT.
Robin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/3] pinctrl: meson-a1: add pinctrl driver for Meson A1 Soc
From: Jerome Brunet @ 2019-09-17 14:07 UTC (permalink / raw)
To: Qianggui Song
Cc: Mark Rutland, Hanjie Lin, Jianxin Pan, Neil Armstrong,
Martin Blumenstingl, Kevin Hilman, Linus Walleij, linux-kernel,
linux-gpio, Rob Herring, linux-arm-kernel, Carlo Caione,
linux-amlogic, Xingyu Chen
In-Reply-To: <73dc56bd-d6c5-1de7-e97e-91479a89a29e@amlogic.com>
On Tue 17 Sep 2019 at 13:51, Qianggui Song <qianggui.song@amlogic.com> wrote:
>>> diff --git a/drivers/pinctrl/meson/pinctrl-meson.c b/drivers/pinctrl/meson/pinctrl-meson.c
>>> index 8bba9d0..885b89d 100644
>>> --- a/drivers/pinctrl/meson/pinctrl-meson.c
>>> +++ b/drivers/pinctrl/meson/pinctrl-meson.c
>>> @@ -688,8 +688,12 @@ static int meson_pinctrl_parse_dt(struct meson_pinctrl *pc,
>>>
>>> pc->reg_ds = meson_map_resource(pc, gpio_np, "ds");
>>> if (IS_ERR(pc->reg_ds)) {
>>> - dev_dbg(pc->dev, "ds registers not found - skipping\n");
>>> - pc->reg_ds = NULL;
>>> + if (pc->data->reg_layout == A1_LAYOUT) {
>>> + pc->reg_ds = pc->reg_pullen;
>>
>> IMO, this kind of ID based init fixup is not going to scale and will
>> lead to something difficult to maintain in the end.
>>
>> The way the different register sets interract with each other is already
>> pretty complex to follow.
>>
>> You could rework this in 2 different ways:
>> #1 - Have the generic function parse all the register sets and have all
>> drivers provide a specific (as in gxbb, gxl, axg, etc ...) function to :
>> - Verify the expected sets have been provided
>> - Make assignement fixup as above if necessary
>>
>> #2 - Rework the driver to have only one single register region
>> I think one of your colleague previously mentionned this was not
>> possible. It is still unclear to me why ...
>>
> Appreciate your advice. I have an idea based on #1, how about providing
> only two dt parse function, one is for chips before A1(the old one),
> another is for A1 and later chips that share the same layout. Assign
> these two functions to their own driver.
That's roughly the same thing as your initial proposition with function
pointer instead of IDs ... IMO, this would still be a quick fix to
address your immediate topic instead of dealing with the driver as
whole, which is my concern here.
>>> + } else {
>>> + dev_dbg(pc->dev, "ds registers not found - skipping\n");
>>> + pc->reg_ds = NULL;
>>> + }
>>> }
>>>
>>> return 0;
>>> diff --git a/drivers/pinctrl/meson/pinctrl-meson.h b/drivers/pinctrl/meson/pinctrl-meson.h
>>> index c696f32..3d0c58d 100644
>>> --- a/drivers/pinctrl/meson/pinctrl-meson.h
>>> +++ b/drivers/pinctrl/meson/pinctrl-meson.h
>>> @@ -80,6 +80,14 @@ enum meson_pinconf_drv {
>>> };
>>>
>>> /**
>>> + * enum meson_reg_layout - identify two types of reg layout
>>> + */
>>> +enum meson_reg_layout {
>>> + LEGACY_LAYOUT,
>>> + A1_LAYOUT,
>>> +};
>>> +
>>> +/**
>>> * struct meson bank
>>> *
>>> * @name: bank name
>>> @@ -114,6 +122,7 @@ struct meson_pinctrl_data {
>>> unsigned int num_banks;
>>> const struct pinmux_ops *pmx_ops;
>>> void *pmx_data;
>>> + unsigned int reg_layout;
>>> };
>>>
>>> struct meson_pinctrl {
>>
>> .
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [REGRESSION] sdhci no longer detects SD cards on LX2160A
From: Russell King - ARM Linux admin @ 2019-09-17 14:12 UTC (permalink / raw)
To: Robin Murphy
Cc: dann frazier, Will Deacon, Adrian Hunter, Nicolin Chen, linux-mmc,
Will Deacon, Christoph Hellwig, Linux ARM
In-Reply-To: <a02d9568-9492-859a-e2ff-4f24171db8a4@arm.com>
On Tue, Sep 17, 2019 at 02:55:51PM +0100, Robin Murphy wrote:
> On 17/09/2019 14:50, Will Deacon wrote:
> > On Tue, Sep 17, 2019 at 02:38:00PM +0100, Robin Murphy wrote:
> > > On 17/09/2019 14:07, Russell King - ARM Linux admin wrote:
> > > > On Tue, Sep 17, 2019 at 01:33:26PM +0100, Russell King - ARM Linux admin wrote:
> > > > > On Tue, Sep 17, 2019 at 12:42:10PM +0100, Russell King - ARM Linux admin wrote:
> > > > > > On Tue, Sep 17, 2019 at 12:16:31PM +0100, Russell King - ARM Linux admin wrote:
> > > > > > > On Tue, Sep 17, 2019 at 11:42:00AM +0100, Russell King - ARM Linux admin wrote:
> > > > > > > > On Tue, Sep 17, 2019 at 09:19:31AM +0100, Russell King - ARM Linux admin wrote:
> > > > > > > > > On Tue, Sep 17, 2019 at 10:06:12AM +0200, Marc Gonzalez wrote:
> > > > > > > > > > On 16/09/2019 19:15, Russell King - ARM Linux admin wrote:
> > > > > > > > > >
> > > > > > > > > > > The platform has an iommu, which is in pass-through mode, via
> > > > > > > > > > > arm_smmu.disable_bypass=0.
> > > > > > > > > >
> > > > > > > > > > Could be 954a03be033c7cef80ddc232e7cbdb17df735663
> > > > > > > > > > "iommu/arm-smmu: Break insecure users by disabling bypass by default"
> > > > > > > > > >
> > > > > > > > > > Although it had already landed in v5.2
> > > > > > > > >
> > > > > > > > > It is not - and the two lines that you quoted above are sufficient
> > > > > > > > > to negate that as a cause. (Please read the help for the option that
> > > > > > > > > the commit referrs to.)
> > > > > > > > >
> > > > > > > > > In fact, with bypass disabled, the SoC fails due to other masters.
> > > > > > > > > That's already been discussed privately between myself and Will
> > > > > > > > > Deacon.
> > > > > > > > >
> > > > > > > > > arm_smmu.disable_bypass=0 re-enables bypass mode irrespective of
> > > > > > > > > the default setting in the Kconfig.
> > > > > > > >
> > > > > > > > Adding some further debugging, and fixing the existing ADMA debugging
> > > > > > > > shows:
> > > > > > > >
> > > > > > > > mmc0: ADMA error: 0x02000000
> > > > > > > >
> > > > > > > > So this is an ADMA error without the transfer having completed.
> > > > > > > >
> > > > > > > > mmc0: sdhci: Blk size: 0x00000008 | Blk cnt: 0x00000001
> > > > > > > >
> > > > > > > > The block size is 8, with one block.
> > > > > > > >
> > > > > > > > mmc0: sdhci: ADMA Err: 0x00000009 | ADMA Ptr: 0x000000236df1d20c
> > > > > > > >
> > > > > > > > The ADMA error is a descriptor error at address 0x000000236df1d20c.
> > > > > > > > The descriptor table contains (including the following entry):
> > > > > > > >
> > > > > > > > mmc0: sdhci: 236df1d200: DMA 0x000000236d40e980, LEN 0x0008, Attr=0x23
> > > > > > > > mmc0: sdhci: 236df1d20c: DMA 0x0000000000000000, LEN 0x0000, Attr=0x00
> > > > > > > >
> > > > > > > > The descriptor table contains one descriptor of 8 bytes, is marked
> > > > > > > > as the last (END bit set) and is at DMA address 0x236df1d200. The
> > > > > > > > following descriptor is empty, with VALID=0.
> > > > > > > >
> > > > > > > > One may be tempted to blame it on the following descriptor, but having
> > > > > > > > had another example on eMMC while userspace was booting (rootfs on
> > > > > > > > eMMC):
> > > > > > > >
> > > > > > > > mmc1: ADMA error: 0x02000000
> > > > > > > > mmc1: sdhci: Blk size: 0x00000200 | Blk cnt: 0x00000099
> > > > > > > > mmc1: sdhci: ADMA Err: 0x00000006 | ADMA Ptr: 0x000000236dbfa26c
> > > > > > > > mmc1: sdhci: 236dbfa200: DMA 0x000000236c25c000, LEN 0x2000, Attr=0x21
> > > > > > > > mmc1: sdhci: 236dbfa20c: DMA 0x000000236938c000, LEN 0x0000, Attr=0x21
> > > > > > > > mmc1: sdhci: 236dbfa218: DMA 0x000000236939c000, LEN 0x5000, Attr=0x21
> > > > > > > > mmc1: sdhci: 236dbfa224: DMA 0x0000002368545000, LEN 0x1000, Attr=0x21
> > > > > > > > mmc1: sdhci: 236dbfa230: DMA 0x00000023684f1000, LEN 0x1000, Attr=0x21
> > > > > > > > mmc1: sdhci: 236dbfa23c: DMA 0x0000002368504000, LEN 0x2000, Attr=0x21
> > > > > > > > mmc1: sdhci: 236dbfa248: DMA 0x0000002368546000, LEN 0x2000, Attr=0x21
> > > > > > > > mmc1: sdhci: 236dbfa254: DMA 0x00000023684f2000, LEN 0x2000, Attr=0x21
> > > > > > > > mmc1: sdhci: 236dbfa260: DMA 0x0000002368500000, LEN 0x1000, Attr=0x23
> > > > > > > > mmc1: sdhci: 236dbfa26c: DMA 0x000000236b55d000, LEN 0x1000, Attr=0x21
> > > > > > > >
> > > > > > > > ... which is interesting for several reasons:
> > > > > > > > - The ADMA error register indicates a length mismatch error. The
> > > > > > > > transfer was for 0x99 blocks of 0x200, which is 0x13200 bytes.
> > > > > > > > Summing the ADMA lengths up to the last descriptor (length=0 is
> > > > > > > > 0x10000 bytes) gives 0x20000 bytes. So the DMA table contains more
> > > > > > > > bytes than the requested transfer.
> > > > > > > >
> > > > > > > > - The ADMA error register indicates ST_CADR, which is described as
> > > > > > > > "This state is never set because do not generate ADMA error in this
> > > > > > > > state."
> > > > > > > >
> > > > > > > > - The error descriptor is again after the descriptor with END=1, but
> > > > > > > > this time has VALID=1.
> > > > > > > >
> > > > > > > > This _feels_ like a coherency issue, where the SDHCI engine is not
> > > > > > > > correctly seeing the descriptor table, but then I would have expected
> > > > > > > > userspace (which is basically debian stable) to fail to boot every
> > > > > > > > time given that its rootfs is on eMMC.
> > > > > > > >
> > > > > > > > The other weird thing is if I wind the core MMC code back via:
> > > > > > > >
> > > > > > > > $ git diff -u 7559d612dff0..v5.3 drivers/mmc/core | patch -p1 -R
> > > > > > > >
> > > > > > > > and fix the lack of dma_max_pfn(), then SDHCI is more stable - not
> > > > > > > > completely stable, but way better than plain v5.3. I don't see
> > > > > > > > much in that diff which would be responsible for this - although it
> > > > > > > > does seem that hch's DMA changes do make the problem more likely.
> > > > > > > > (going from 1 in 3 boots with a problem to being not able to boot.)
> > > > > > > >
> > > > > > > > Note, with v5.2, I _never_ saw any ADMA errors, except if I disabled
> > > > > > > > bypass mode on the IOMMU (but then I saw global smmu errors right
> > > > > > > > from when the IOMMU had bypass disabled before MMC was probed - the
> > > > > > > > reason being is the SoC is not currently setup to have the MMU
> > > > > > > > bypass mode disabled.)
> > > > > > >
> > > > > > > This looks like an ARM64 coherency issue.
> > > > > > >
> > > > > > > I first tried adding a dma_wmb() to the end of sdhci_adma_table_pre(),
> > > > > > > which had no effect. I then tried adding:
> > > > > > >
> > > > > > > + __dma_flush_area(host->adma_table, desc - host->adma_table);
> > > > > > > + dma_wmb();
> > > > > > >
> > > > > > > and so far I haven't had any further ADMA errors. Adding Will Deacon
> > > > > > > to the thread.
> > > > > >
> > > > > > These are the changes to sdhci that I'm currently running. I think
> > > > > > some of the debugging related changes are probably worth adding to
> > > > > > the driver, particularly printing the intmask on ADMA error (which
> > > > > > is not printed by the register dump, as the value is lost) and printing
> > > > > > the DMA addresses of the descriptor table entries which can be tied
> > > > > > up with the DMA address error register. Also, maybe printing the
> > > > > > DMA descriptor table with the register dump, rather than having to
> > > > > > resort to enabling debug would be a good idea?
> > > > > >
> > > > > > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> > > > > > index a5dc5aae973e..884dcaa9cad5 100644
> > > > > > --- a/drivers/mmc/host/sdhci.c
> > > > > > +++ b/drivers/mmc/host/sdhci.c
> > > > > > @@ -773,6 +773,8 @@ static void sdhci_adma_table_pre(struct sdhci_host *host,
> > > > > > /* Add a terminating entry - nop, end, valid */
> > > > > > __sdhci_adma_write_desc(host, &desc, 0, 0, ADMA2_NOP_END_VALID);
> > > > > > }
> > > > > > + __dma_flush_area(host->adma_table, desc - host->adma_table);
> > > > > > + dma_wmb();
> > > > > > }
> > > > > > static void sdhci_adma_table_post(struct sdhci_host *host,
> > > > > > @@ -2855,6 +2857,8 @@ static void sdhci_cmd_irq(struct sdhci_host *host, u32 intmask, u32 *intmask_p)
> > > > > > static void sdhci_adma_show_error(struct sdhci_host *host)
> > > > > > {
> > > > > > void *desc = host->adma_table;
> > > > > > + dma_addr_t dma = host->adma_addr;
> > > > > > + bool end = false;
> > > > > > sdhci_dumpregs(host);
> > > > > > @@ -2862,21 +2866,26 @@ static void sdhci_adma_show_error(struct sdhci_host *host)
> > > > > > struct sdhci_adma2_64_desc *dma_desc = desc;
> > > > > > if (host->flags & SDHCI_USE_64_BIT_DMA)
> > > > > > - DBG("%p: DMA 0x%08x%08x, LEN 0x%04x, Attr=0x%02x\n",
> > > > > > - desc, le32_to_cpu(dma_desc->addr_hi),
> > > > > > + SDHCI_DUMP("%08llx: DMA 0x%08x%08x, LEN 0x%04x, Attr=0x%02x\n",
> > > > > > + (unsigned long long)dma,
> > > > > > + le32_to_cpu(dma_desc->addr_hi),
> > > > > > le32_to_cpu(dma_desc->addr_lo),
> > > > > > le16_to_cpu(dma_desc->len),
> > > > > > le16_to_cpu(dma_desc->cmd));
> > > > > > else
> > > > > > - DBG("%p: DMA 0x%08x, LEN 0x%04x, Attr=0x%02x\n",
> > > > > > - desc, le32_to_cpu(dma_desc->addr_lo),
> > > > > > + SDHCI_DUMP("%08llx: DMA 0x%08x, LEN 0x%04x, Attr=0x%02x\n",
> > > > > > + (unsigned long long)dma,
> > > > > > + le32_to_cpu(dma_desc->addr_lo),
> > > > > > le16_to_cpu(dma_desc->len),
> > > > > > le16_to_cpu(dma_desc->cmd));
> > > > > > + if (end) break;
> > > > > > +
> > > > > > desc += host->desc_sz;
> > > > > > + dma += host->desc_sz;
> > > > > > if (dma_desc->cmd & cpu_to_le16(ADMA2_END))
> > > > > > - break;
> > > > > > + end = true;
> > > > > > }
> > > > > > }
> > > > > > @@ -2949,7 +2958,7 @@ static void sdhci_data_irq(struct sdhci_host *host, u32 intmask)
> > > > > > != MMC_BUS_TEST_R)
> > > > > > host->data->error = -EILSEQ;
> > > > > > else if (intmask & SDHCI_INT_ADMA_ERROR) {
> > > > > > - pr_err("%s: ADMA error\n", mmc_hostname(host->mmc));
> > > > > > + pr_err("%s: ADMA error: 0x%08x\n", mmc_hostname(host->mmc), intmask);
> > > > > > sdhci_adma_show_error(host);
> > > > > > host->data->error = -EIO;
> > > > > > if (host->ops->adma_workaround)
> > > > >
> > > > > Further debug shows:
> > > > >
> > > > > coherent=0 - sdhci device is not cache coherent
> > > > > swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000081cac000
> > > > > [ffffff8010fd5200] pgd=000000237ffff003, pud=000000237ffff003,
> > > > > pmd=000000237fffb003, pte=00e800236d62270f
> > > > >
> > > > > The mapping for the ADMA table seems to be using MAIR index 3, which is
> > > > > MT_MEMORY_NC, so should be non-cacheable.
> > > > >
> > > > > vmallocinfo:
> > > > > 0xffffff8010fd5000-0xffffff8010fd7000 8192 dma_direct_alloc+0x4c/0x54
> > > > > user
> > > > >
> > > > > So this memory has been remapped. Could there be an alias that has
> > > > > cache lines still in the cache for the physical address, and could we
> > > > > be hitting those cache lines while accessing through a non-cacheable
> > > > > mapping? (On 32-bit ARM, this is "unpredictable" and this problem
> > > > > definitely _feels_ like it has unpredictable attributes!)
> > > > >
> > > > > Also, given that this memory is mapped NC, then surely
> > > > > __dma_flush_area() should have no effect? However, it _does_ have the
> > > > > effect of reliably solving the problem, which to me implies that there
> > > > > _are_ cache lines in this NC mapping.
> > > >
> > > > Will suggested reverting bd2e75633c80 ("dma-contiguous: use fallback
> > > > alloc_pages for single pages") which has been implicated in the same
> > > > problem here:
> > > >
> > > > https://www.spinics.net/lists/arm-kernel/msg750623.html
> > > >
> > > > Although reverting the commit is not clean, this also fixes the issue
> > > > for me.
> > >
> > > Note that that one turned out to be something totally different, namely that
> > > the single-page allocations, in difference to CMA, came from physical
> > > addresses that the controller needed additional configuration to be able to
> > > access[1] - no amount of cache maintenance would affect that.
> >
> > To be honest, the conclusion in that other thread wasn't exactly satisfying.
> > The reporter says "Probably, my device is not 64-bit capable." and the fix
> > changes the buffer allocation enough that I wouldn't rule out the same
> > coherency issue as being the root cause. I don't think we ever tried adding
> > cache flushing to see if it helped.
>
> Huh? The conclusion of that thread seemed pretty clear to me:
>
> https://lore.kernel.org/linux-arm-kernel/CAK7LNASs2qkpGY_BkL--hvmKm3FJ9sEK4+v5VVYc1_CrowAB4w@mail.gmail.com/
>
> which is where I linked that patch from :/
... and it is looking like the conclusion of that was incorrect given
that I'm seeing the same issue on hardware that isn't capable of v4
operation but is capable of addressing the full range of system memory.
I can confirm that the registers that set the ADMA table base are 64-bit
wide in the LX2160A reference manual.
I can also confirm that the eSDHC driver is using 96-bit descriptor
format, which is what is required to support 64-bit DMA addresses, and
the eSDHC hardware supports this format.
So, this does _not_ appear to be some addressing limitation of the
device.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 2/9] dt-bindings: i2c: add bindings for i2c analog and digital filter
From: Rob Herring @ 2019-09-17 14:28 UTC (permalink / raw)
To: Eugen.Hristev
Cc: mark.rutland, devicetree, alexandre.belloni, wsa, linux-kernel,
Ludovic.Desroches, linux-i2c, peda, linux-arm-kernel
In-Reply-To: <1568189911-31641-3-git-send-email-eugen.hristev@microchip.com>
On Wed, Sep 11, 2019 at 08:24:20AM +0000, Eugen.Hristev@microchip.com wrote:
> From: Eugen Hristev <eugen.hristev@microchip.com>
>
> Some i2c controllers have a built-in digital or analog filter.
> This is specifically required depending on the hardware PCB/board.
> Some controllers also allow specifying the maximum width of the
> spikes that can be filtered for digital filter. The width length can be
> specified in nanoseconds.
> Analog filters can be configured to have a cutoff frequency (low-pass filter).
> This frequency can be specified in Hz.
> Added an optional property for such types of analog filters.
>
> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
> ---
> Documentation/devicetree/bindings/i2c/i2c.txt | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 0/8] OMAP3: convert opp-v1 to opp-v2 and read speed binned / 720MHz grade bits
From: H. Nikolaus Schaller @ 2019-09-17 14:35 UTC (permalink / raw)
To: Tony Lindgren
Cc: Mark Rutland, devicetree, letux-kernel, linux-pm,
Enric Balletbo i Serra, Viresh Kumar, Rafael J. Wysocki,
linux-kernel, Rob Herring, André Roth, Benoît Cousson,
kernel, Teresa Remmet, Javier Martinez Canillas, linux-omap,
Adam Ford, linux-arm-kernel, Roger Quadros
In-Reply-To: <20190916162816.GF52127@atomide.com>
Hi Tony,
> Am 16.09.2019 um 18:28 schrieb Tony Lindgren <tony@atomide.com>:
>
> * H. Nikolaus Schaller <hns@goldelico.com> [190911 17:48]:
>> CHANGES V3:
>> * make omap36xx control the abb-ldo and properly switch mode
>> (suggested by Adam Ford <aford173@gmail.com>)
>> * add a note about enabling the turbo-mode OPPs
>
> Looks good to me, when applying, please provide a
> minimal immutable branch maybe against v5.3 or v5.4-rc1,
> that I can also merge in if needed for the dts changes.
Should I resend a v4 with your Acked-By added?
BR and thanks,
Nikolaus
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 01/11] kselftest: arm64: extend toplevel skeleton Makefile
From: Anders Roxell @ 2019-09-17 13:42 UTC (permalink / raw)
To: Cristian Marussi
Cc: andreyknvl, linux-kselftest, amit.kachhap, shuah, dave.martin,
linux-arm-kernel
In-Reply-To: <20190910123111.33478-2-cristian.marussi@arm.com>
On 2019-09-10 13:31, Cristian Marussi wrote:
> Modify KSFT arm64 toplevel Makefile to maintain arm64 kselftests organized
> by subsystem, keeping them into distinct subdirectories under arm64 custom
> KSFT directory: tools/testing/selftests/arm64/
>
> Add to such toplevel Makefile a mechanism to guess the effective location
> of Kernel headers as installed by KSFT framework.
>
> Fit existing arm64 tags kselftest into this new schema moving them into
> their own subdirectory (arm64/tags).
>
> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> ---
> Based on:
> commit 9ce1263033cd ("selftests, arm64: add a selftest for passing
> tagged pointers to kernel")
> ---
> v5 --> v6
> - using realpath to avoid passing down relative paths
> - fix commit msg & Copyright
> - removed unneded Makefile export
> - added SUBTARGETS specification, to allow building specific only some
> arm64 test subsystems
> v4 --> v5
> - rebased on arm64/for-next/core
> - merged this patch with KSFT arm64 tags patch, while moving the latter
> into its own subdir
> - moved kernel header includes search mechanism from KSFT arm64
> SIGNAL Makefile
> - export proper top_srcdir ENV for lib.mk
> v3 --> v4
> - comment reword
> - simplified documentation in README
> - dropped README about standalone
> ---
> tools/testing/selftests/Makefile | 1 +
> tools/testing/selftests/arm64/Makefile | 63 +++++++++++++++++--
> tools/testing/selftests/arm64/README | 25 ++++++++
> tools/testing/selftests/arm64/tags/Makefile | 6 ++
> .../arm64/{ => tags}/run_tags_test.sh | 0
> .../selftests/arm64/{ => tags}/tags_test.c | 0
> 6 files changed, 91 insertions(+), 4 deletions(-)
> create mode 100644 tools/testing/selftests/arm64/README
> create mode 100644 tools/testing/selftests/arm64/tags/Makefile
> rename tools/testing/selftests/arm64/{ => tags}/run_tags_test.sh (100%)
> rename tools/testing/selftests/arm64/{ => tags}/tags_test.c (100%)
>
> diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
> index 25b43a8c2b15..1722dae9381a 100644
> --- a/tools/testing/selftests/Makefile
> +++ b/tools/testing/selftests/Makefile
> @@ -1,5 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0
> TARGETS = android
> +TARGETS += arm64
> TARGETS += bpf
> TARGETS += breakpoints
> TARGETS += capabilities
> diff --git a/tools/testing/selftests/arm64/Makefile b/tools/testing/selftests/arm64/Makefile
> index a61b2e743e99..cbb2a5a9e3fc 100644
> --- a/tools/testing/selftests/arm64/Makefile
> +++ b/tools/testing/selftests/arm64/Makefile
> @@ -1,11 +1,66 @@
> # SPDX-License-Identifier: GPL-2.0
>
> -# ARCH can be overridden by the user for cross compiling
> +# When ARCH not overridden for crosscompiling, lookup machine
> ARCH ?= $(shell uname -m 2>/dev/null || echo not)
>
> ifneq (,$(filter $(ARCH),aarch64 arm64))
> -TEST_GEN_PROGS := tags_test
> -TEST_PROGS := run_tags_test.sh
> +SUBTARGETS ?= tags
> +else
> +SUBTARGETS :=
> endif
>
> -include ../lib.mk
> +CFLAGS := -Wall -O2 -g
> +
> +# A proper top_srcdir is needed by KSFT(lib.mk)
> +top_srcdir = $(realpath ../../../../)
> +
> +# Additional include paths needed by kselftest.h and local headers
> +CFLAGS += -I$(top_srcdir)/tools/testing/selftests/
> +
> +# Guessing where the Kernel headers could have been installed
> +# depending on ENV config
> +ifeq ($(KBUILD_OUTPUT),)
> +khdr_dir = $(top_srcdir)/usr/include
> +else
> +# the KSFT preferred location when KBUILD_OUTPUT is set
> +khdr_dir = $(KBUILD_OUTPUT)/kselftest/usr/include
> +endif
> +
> +CFLAGS += -I$(khdr_dir)
> +
> +export CFLAGS
> +export top_srcdir
> +
> +all:
> + @for DIR in $(SUBTARGETS); do \
> + BUILD_TARGET=$(OUTPUT)/$$DIR; \
> + mkdir -p $$BUILD_TARGET; \
> + make OUTPUT=$$BUILD_TARGET -C $$DIR $@; \
> + done
> +
> +install: all
> + @for DIR in $(SUBTARGETS); do \
> + BUILD_TARGET=$(OUTPUT)/$$DIR; \
> + make OUTPUT=$$BUILD_TARGET -C $$DIR $@; \
> + done
> +
> +run_tests: all
> + @for DIR in $(SUBTARGETS); do \
> + BUILD_TARGET=$(OUTPUT)/$$DIR; \
> + make OUTPUT=$$BUILD_TARGET -C $$DIR $@; \
> + done
> +
> +# Avoid any output on non arm64 on emit_tests
> +emit_tests: all
> + @for DIR in $(SUBTARGETS); do \
> + BUILD_TARGET=$(OUTPUT)/$$DIR; \
> + make OUTPUT=$$BUILD_TARGET -C $$DIR $@; \
> + done
> +
> +clean:
> + @for DIR in $(SUBTARGETS); do \
> + BUILD_TARGET=$(OUTPUT)/$$DIR; \
> + make OUTPUT=$$BUILD_TARGET -C $$DIR $@; \
> + done
> +
> +.PHONY: all clean install run_tests emit_tests
> diff --git a/tools/testing/selftests/arm64/README b/tools/testing/selftests/arm64/README
> new file mode 100644
> index 000000000000..cc1e51796fee
> --- /dev/null
> +++ b/tools/testing/selftests/arm64/README
> @@ -0,0 +1,25 @@
> +KSelfTest ARM64
> +===============
> +
> +- These tests are arm64 specific and so not built or run but just skipped
> + completely when env-variable ARCH is found to be different than 'arm64'
> + and `uname -m` reports other than 'aarch64'.
> +
> +- Holding true the above, ARM64 KSFT tests can be run within the KSelfTest
> + framework using standard Linux top-level-makefile targets:
> +
> + $ make TARGETS=arm64 kselftest-clean
> + $ make TARGETS=arm64 kselftest
> +
> + or
> +
> + $ make -C tools/testing/selftests TARGETS=arm64 \
> + INSTALL_PATH=<your-installation-path> install
> +
> + or, alternatively, only specific arm64/ subtargets can be picked:
> +
> + $ make -C tools/testing/selftests TARGETS=arm64 SUBTARGETS="tags signal" \
> + INSTALL_PATH=<your-installation-path> install
> +
> + Further details on building and running KFST can be found in:
> + Documentation/dev-tools/kselftest.rst
> diff --git a/tools/testing/selftests/arm64/tags/Makefile b/tools/testing/selftests/arm64/tags/Makefile
> new file mode 100644
> index 000000000000..dcc8b0467b68
> --- /dev/null
> +++ b/tools/testing/selftests/arm64/tags/Makefile
> @@ -0,0 +1,6 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +TEST_GEN_PROGS := tags_test
This should be TEST_GEN_FILES, since its used by run_tags_test.sh.
If its TEST_GEN_PROGS it will be added to the script run_kselftest.sh,
and I don't think thats the intent, even though it looked like that
before.
Cheers,
Anders
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 0/2] improve the concurrency of arm_smmu_atc_inv_domain()
From: Leizhen (ThunderTown) @ 2019-09-17 14:35 UTC (permalink / raw)
To: Will Deacon; +Cc: Jean-Philippe Brucker, iommu, Robin Murphy, linux-arm-kernel
In-Reply-To: <7e28e1ce-2cc3-3c7f-45c7-e7de334c6976@huawei.com>
On 2019/8/23 16:06, Leizhen (ThunderTown) wrote:
>
>
> On 2019/8/23 15:50, Will Deacon wrote:
>> On Fri, Aug 23, 2019 at 10:45:49AM +0800, Zhen Lei wrote:
>>> v2 --> v3:
>>> As Will Deacon's suggestion, I changed the lock type of
>>> arm_smmu_domain.devices_lock from spinlock_t to rwlock_t, and I saw that the
>>> performance is all right. And further use nr_ats_masters to quickly check have
>>> no obvious effect, so I drop it.
>>
>> :/
>>
>> I already sent two versions of a series fixing this without any locking at
>> all on the ->unmap() path, and you were on cc. I've also queued that stuff
>> up.
>>
>> Did you not receive my patches?
> Sorry, my message filter setting is a bit wrong, must contains
> "linux-kernel@vger.kernel.org", I have corrected it.
>
>>
>> v1: https://lists.linuxfoundation.org/pipermail/iommu/2019-August/038306.html
>> v2: https://lists.linuxfoundation.org/pipermail/iommu/2019-August/038374.html
> OK, I will test it when it's my turn to use the board.
The test result shows good to me, without these patches, it's about 22xx-23xx
Jobs: 24 (f=24): [RRRRRRRRRRRRRRRRRRRRRRRR] [0.6% done] [11160M/0K /s] [2725K/0
Jobs: 24 (f=24): [RRRRRRRRRRRRRRRRRRRRRRRR] [0.6% done] [11165M/0K /s] [2726K/0
Jobs: 24 (f=24): [RRRRRRRRRRRRRRRRRRRRRRRR] [0.6% done] [11220M/0K /s] [2739K/0
Jobs: 24 (f=24): [RRRRRRRRRRRRRRRRRRRRRRRR] [0.6% done] [11189M/0K /s] [2732K/0
Jobs: 24 (f=24): [RRRRRRRRRRRRRRRRRRRRRRRR] [0.6% done] [11082M/0K /s] [2705K/0
Jobs: 24 (f=24): [RRRRRRRRRRRRRRRRRRRRRRRR] [0.6% done] [11003M/0K /s] [2686K/0
Jobs: 24 (f=24): [RRRRRRRRRRRRRRRRRRRRRRRR] [0.6% done] [11412M/0K /s] [2786K/0
Jobs: 24 (f=24): [RRRRRRRRRRRRRRRRRRRRRRRR] [0.6% done] [11415M/0K /s] [2787K/0
Jobs: 24 (f=24): [RRRRRRRRRRRRRRRRRRRRRRRR] [0.6% done] [11214M/0K /s] [2738K/0
Jobs: 24 (f=24): [RRRRRRRRRRRRRRRRRRRRRRRR] [0.6% done] [11054M/0K /s] [2699K/0
Jobs: 24 (f=24): [RRRRRRRRRRRRRRRRRRRRRRRR] [0.6% done] [10733M/0K /s] [2620K/0
Jobs: 24 (f=24): [RRRRRRRRRRRRRRRRRRRRRRRR] [0.6% done] [10772M/0K /s] [2630K/0
Jobs: 24 (f=24): [RRRRRRRRRRRRRRRRRRRRRRRR] [0.7% done] [10772M/0K /s] [2630K/0
>
>>
>> Queued: https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/log/?h=for-joerg/arm-smmu/smmu-v3
>>
>> Will
>>
>> .
>>
>
> _______________________________________________
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH RESEND V5 1/5] dt-bindings: fsl: scu: add scu key binding
From: Rob Herring @ 2019-09-17 14:37 UTC (permalink / raw)
To: Anson Huang
Cc: mark.rutland, ulf.hansson, ping.bai, catalin.marinas, peng.fan,
stefan, bjorn.andersson, leonard.crestez, will, festevam,
yuehaibing, marcin.juszkiewicz, cw00.choi, jagan, linux-input,
ronald, Linux-imx, devicetree, arnd, s.hauer, mripard, m.felsch,
enric.balletbo, robh+dt, andriy.shevchenko, daniel.baluta,
linux-arm-kernel, aisheng.dong, fugang.duan, dmitry.torokhov,
linux-kernel, dinguyen, kernel, olof, shawnguo
In-Reply-To: <1568689939-8871-1-git-send-email-Anson.Huang@nxp.com>
On Tue, 17 Sep 2019 11:12:15 +0800, Anson Huang wrote:
> NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as
> system controller, the system controller is in charge of system
> power, clock and scu key event etc. management, Linux kernel has
> to communicate with system controller via MU (message unit) IPC
> to get scu key event, add binding doc for i.MX system controller
> key driver.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> No changes.
> ---
> .../devicetree/bindings/arm/freescale/fsl,scu.txt | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
Please add Acked-by/Reviewed-by tags when posting new versions. However,
there's no need to repost patches *only* to add the tags. The upstream
maintainer will do that for acks received on the version they apply.
If a tag was not added on purpose, please state why and what changed.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/2] ARM: dts: imx6q: Enable CAN in board DTS
From: Marek Vasut @ 2019-09-17 14:37 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Shawn Guo, Fabio Estevam, NXP Linux Team,
Ludwig Zenz
Move the CAN enablement from SoM DTSi to board DTS, as each board might need
different CAN configuration. Moreover, disable CAN2 on the PDK2 as it is not
available on any connector. This also fixes on-SoM SD slot operation, as it
shares pins with the CAN2.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Ludwig Zenz <lzenz@dh-electronics.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: NXP Linux Team <linux-imx@nxp.com>
To: linux-arm-kernel@lists.infradead.org
---
arch/arm/boot/dts/imx6q-dhcom-pdk2.dts | 8 ++++++++
arch/arm/boot/dts/imx6q-dhcom-som.dtsi | 2 --
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q-dhcom-pdk2.dts b/arch/arm/boot/dts/imx6q-dhcom-pdk2.dts
index 9c61e3be2d9a..5219553df1e7 100644
--- a/arch/arm/boot/dts/imx6q-dhcom-pdk2.dts
+++ b/arch/arm/boot/dts/imx6q-dhcom-pdk2.dts
@@ -43,6 +43,14 @@
status = "okay";
};
+&can1 {
+ status = "okay";
+};
+
+&can2 {
+ status = "disabled";
+};
+
&hdmi {
ddc-i2c-bus = <&i2c2>;
status = "okay";
diff --git a/arch/arm/boot/dts/imx6q-dhcom-som.dtsi b/arch/arm/boot/dts/imx6q-dhcom-som.dtsi
index 387801dde02e..845cfad99bf9 100644
--- a/arch/arm/boot/dts/imx6q-dhcom-som.dtsi
+++ b/arch/arm/boot/dts/imx6q-dhcom-som.dtsi
@@ -51,13 +51,11 @@
&can1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_flexcan1>;
- status = "okay";
};
&can2 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_flexcan2>;
- status = "okay";
};
&ecspi1 {
--
2.23.0.rc1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: imx6q: Add ethernet PHY power GPIO
From: Marek Vasut @ 2019-09-17 14:37 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Shawn Guo, Fabio Estevam, NXP Linux Team,
Ludwig Zenz
In-Reply-To: <20190917143714.12876-1-marex@denx.de>
Add missing ethernet PHY power GPIO.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Ludwig Zenz <lzenz@dh-electronics.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: NXP Linux Team <linux-imx@nxp.com>
To: linux-arm-kernel@lists.infradead.org
---
arch/arm/boot/dts/imx6q-dhcom-som.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/imx6q-dhcom-som.dtsi b/arch/arm/boot/dts/imx6q-dhcom-som.dtsi
index 845cfad99bf9..687caedf0784 100644
--- a/arch/arm/boot/dts/imx6q-dhcom-som.dtsi
+++ b/arch/arm/boot/dts/imx6q-dhcom-som.dtsi
@@ -86,6 +86,7 @@
pinctrl-0 = <&pinctrl_enet_100M>;
phy-mode = "rmii";
phy-handle = <ðphy0>;
+ power-gpios = <&gpio1 7 GPIO_ACTIVE_LOW>;
status = "okay";
mdio {
--
2.23.0.rc1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [V2, 1/2] media: dt-bindings: media: i2c: Add bindings for ov8856
From: Rob Herring @ 2019-09-17 14:44 UTC (permalink / raw)
To: Sakari Ailus
Cc: mark.rutland, devicetree, drinkcat, srv_heupstream, shengnan.wang,
Andy Shevchenko, tfiga, louis.kuo, sj.huang, linux-mediatek,
dongchun.zhu, matthias.bgg, bingbu.cao, mchehab, linux-arm-kernel,
linux-media
In-Reply-To: <20190917120205.GO5781@paasikivi.fi.intel.com>
On Tue, Sep 17, 2019 at 03:02:06PM +0300, Sakari Ailus wrote:
> On Tue, Sep 10, 2019 at 08:37:43PM +0300, Andy Shevchenko wrote:
> > On Tue, Sep 10, 2019 at 09:04:45PM +0800, dongchun.zhu@mediatek.com wrote:
> > > From: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > >
> > > This patch adds device tree bindings documentation for the ov8856 CMOS
> > > image sensor.
> >
> > New bindings in YAML, please.
>
> My understanding is text documents are still fine.
Schema are preferred, but still up to the subsystem for now.
> We don't have things like graph.txt or video-interfaces.txt in YAML yet
> either.
That doesn't really matter too much. You can assume common properties
will have a common schema and just define what's device specific. The
device specific bindings have to define 'port' or 'port@N' nodes.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2] iommu/arm-smmu: Report USF more clearly
From: Robin Murphy @ 2019-09-17 14:45 UTC (permalink / raw)
To: will, joro; +Cc: iommu, Douglas Anderson, linux-arm-kernel
Although CONFIG_ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT is a welcome tool
for smoking out inadequate firmware, the failure mode is non-obvious
and can be confusing for end users. Add some special-case reporting of
Unidentified Stream Faults to help clarify this particular symptom.
Since we're adding yet another print to the mix, also break out an
explicit ratelimit state to make sure everything stays together (and
reduce the static storage footprint a little).
CC: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/arm-smmu.c | 21 ++++++++++++++++-----
drivers/iommu/arm-smmu.h | 2 ++
2 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index b7cf24402a94..b27020fd6c90 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -36,6 +36,7 @@
#include <linux/pci.h>
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
+#include <linux/ratelimit.h>
#include <linux/slab.h>
#include <linux/amba/bus.h>
@@ -485,6 +486,8 @@ static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
{
u32 gfsr, gfsynr0, gfsynr1, gfsynr2;
struct arm_smmu_device *smmu = dev;
+ static DEFINE_RATELIMIT_STATE(rs, DEFAULT_RATELIMIT_INTERVAL,
+ DEFAULT_RATELIMIT_BURST);
gfsr = arm_smmu_gr0_read(smmu, ARM_SMMU_GR0_sGFSR);
gfsynr0 = arm_smmu_gr0_read(smmu, ARM_SMMU_GR0_sGFSYNR0);
@@ -494,11 +497,19 @@ static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
if (!gfsr)
return IRQ_NONE;
- dev_err_ratelimited(smmu->dev,
- "Unexpected global fault, this could be serious\n");
- dev_err_ratelimited(smmu->dev,
- "\tGFSR 0x%08x, GFSYNR0 0x%08x, GFSYNR1 0x%08x, GFSYNR2 0x%08x\n",
- gfsr, gfsynr0, gfsynr1, gfsynr2);
+ if (__ratelimit(&rs)) {
+ if (IS_ENABLED(CONFIG_ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT) &&
+ (gfsr & sGFSR_USF))
+ dev_err(smmu->dev,
+ "Blocked unknown Stream ID 0x%hx; boot with \"arm-smmu.disable_bypass=0\" to allow, but this may have security implications\n",
+ (u16)gfsynr1);
+ else
+ dev_err(smmu->dev,
+ "Unexpected global fault, this could be serious\n");
+ dev_err(smmu->dev,
+ "\tGFSR 0x%08x, GFSYNR0 0x%08x, GFSYNR1 0x%08x, GFSYNR2 0x%08x\n",
+ gfsr, gfsynr0, gfsynr1, gfsynr2);
+ }
arm_smmu_gr0_write(smmu, ARM_SMMU_GR0_sGFSR, gfsr);
return IRQ_HANDLED;
diff --git a/drivers/iommu/arm-smmu.h b/drivers/iommu/arm-smmu.h
index c9c13b5785f2..eede28ecda6d 100644
--- a/drivers/iommu/arm-smmu.h
+++ b/drivers/iommu/arm-smmu.h
@@ -79,6 +79,8 @@
#define ID7_MINOR GENMASK(3, 0)
#define ARM_SMMU_GR0_sGFSR 0x48
+#define sGFSR_USF BIT(1)
+
#define ARM_SMMU_GR0_sGFSYNR0 0x50
#define ARM_SMMU_GR0_sGFSYNR1 0x54
#define ARM_SMMU_GR0_sGFSYNR2 0x58
--
2.21.0.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH V7 3/3] arm64/mm: Enable memory hot remove
From: Catalin Marinas @ 2019-09-17 15:08 UTC (permalink / raw)
To: Anshuman Khandual
Cc: mark.rutland, mhocko, david, linux-mm, arunks, cpandya, ira.weiny,
will, steven.price, valentin.schneider, suzuki.poulose,
Robin.Murphy, broonie, cai, ard.biesheuvel, dan.j.williams,
linux-arm-kernel, osalvador, steve.capper, logang, linux-kernel,
akpm, mgorman
In-Reply-To: <a1962cde-b4df-e4a0-de61-252c0d0a25b2@arm.com>
On Tue, Sep 17, 2019 at 10:06:11AM +0530, Anshuman Khandual wrote:
> On 09/13/2019 03:39 PM, Catalin Marinas wrote:
> > On Fri, Sep 13, 2019 at 11:28:01AM +0530, Anshuman Khandual wrote:
> >> The problem (race) is not because of the inability to deal with partially
> >> filled table. We can handle that correctly as explained below [1]. The
> >> problem is with inadequate kernel page table locking during vmalloc()
> >> which might be accessing intermediate kernel page table pointers which is
> >> being freed with free_empty_tables() concurrently. Hence we cannot free
> >> any page table page which can ever have entries from vmalloc() range.
> >
> > The way you deal with the partially filled table in this patch is to
> > avoid freeing if there is a non-empty entry (!p*d_none()). This is what
> > causes the race with vmalloc. If you simply avoid freeing a pmd page,
> > for example, if the range floor/ceiling is not aligned to PUD_SIZE,
> > irrespective of whether the other entries are empty or not, you
> > shouldn't have this problem. You do free the pte page if the range is
[...]
> > We may have some pgtable pages not freed at both ends of the range
> > (maximum 6 in total) but I don't really see this an issue. They could be
> > reused if something else gets mapped in that range.
>
> I assume that the number 6 for maximum page possibility came from
>
> (floor edge + ceiling edge) * (PTE table + PMD table + PUD table)
Yes.
> >> Though not completely sure, whether I really understood the suggestion above
> >> with respect to the floor-ceiling mechanism as in free_pgd_range(). Are you
> >> suggesting that we should only attempt to free up those vmemmap range page
> >> table pages which *definitely* could never overlap with vmalloc by working
> >> on a modified (i.e cut down with floor-ceiling while avoiding vmalloc range
> >> at each level) vmemmap range instead ?
> >
> > You can ignore the overlap check altogether, only free the page tables
> > with floor/ceiling set to the start/size passed to arch_remove_memory()
> > and vmemmap_free().
>
> Wondering if it will be better to use [VMEMMAP_START - VMEMMAP_END] and
> [PAGE_OFFSET - PAGE_END] as floor/ceiling respectively with vmemmap_free()
> and arch_remove_memory(). Not only it is safe to free all page table pages
> which span over these maximum possible mapping range but also it reduces
> the risk for alignment related wastage.
That's indeed better. You pass the floor/ceiling as the enclosing range
and start/end as the actual range to unmap is. We avoid the potential
"leak" around the edges when falling within the floor/ceiling range (I
think that's close to what free_pgd_range() does).
> >> This can be one restrictive version of the function
> >> free_empty_tables() called in case there is an overlap. So we will
> >> maintain two versions for free_empty_tables(). Please correct me if
> >> any the above assumptions or understanding is wrong.
> >
> > I'd rather have a single version of free_empty_tables(). As I said
> > above, the only downside is that a partially filled pgtable page would
> > not be freed even though the other entries are empty.
>
> Sure. Also practically the limitation will be applicable only for vmemmap
> mapping but not for linear mappings where the chances of overlap might be
> negligible as it covers half kernel virtual address space.
If you have a common set of functions, it doesn't heart to pass the
correct floor/ceiling in both cases.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 01/11] kselftest: arm64: extend toplevel skeleton Makefile
From: Cristian Marussi @ 2019-09-17 15:17 UTC (permalink / raw)
To: Anders Roxell
Cc: andreyknvl, linux-kselftest, amit.kachhap, shuah, dave.martin,
linux-arm-kernel
In-Reply-To: <20190917134223.GA2695@localhost.localdomain>
Hi Anders
thanks for the review.
On 17/09/2019 14:42, Anders Roxell wrote:
> On 2019-09-10 13:31, Cristian Marussi wrote:
>> Modify KSFT arm64 toplevel Makefile to maintain arm64 kselftests organized
>> by subsystem, keeping them into distinct subdirectories under arm64 custom
>> KSFT directory: tools/testing/selftests/arm64/
>>
>> Add to such toplevel Makefile a mechanism to guess the effective location
>> of Kernel headers as installed by KSFT framework.
>>
>> Fit existing arm64 tags kselftest into this new schema moving them into
>> their own subdirectory (arm64/tags).
>>
>> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
>> ---
>> Based on:
>> commit 9ce1263033cd ("selftests, arm64: add a selftest for passing
>> tagged pointers to kernel")
>> ---
>> v5 --> v6
>> - using realpath to avoid passing down relative paths
>> - fix commit msg & Copyright
>> - removed unneded Makefile export
>> - added SUBTARGETS specification, to allow building specific only some
>> arm64 test subsystems
>> v4 --> v5
>> - rebased on arm64/for-next/core
>> - merged this patch with KSFT arm64 tags patch, while moving the latter
>> into its own subdir
>> - moved kernel header includes search mechanism from KSFT arm64
>> SIGNAL Makefile
>> - export proper top_srcdir ENV for lib.mk
>> v3 --> v4
>> - comment reword
>> - simplified documentation in README
>> - dropped README about standalone
>> ---
>> tools/testing/selftests/Makefile | 1 +
>> tools/testing/selftests/arm64/Makefile | 63 +++++++++++++++++--
>> tools/testing/selftests/arm64/README | 25 ++++++++
>> tools/testing/selftests/arm64/tags/Makefile | 6 ++
>> .../arm64/{ => tags}/run_tags_test.sh | 0
>> .../selftests/arm64/{ => tags}/tags_test.c | 0
>> 6 files changed, 91 insertions(+), 4 deletions(-)
>> create mode 100644 tools/testing/selftests/arm64/README
>> create mode 100644 tools/testing/selftests/arm64/tags/Makefile
>> rename tools/testing/selftests/arm64/{ => tags}/run_tags_test.sh (100%)
>> rename tools/testing/selftests/arm64/{ => tags}/tags_test.c (100%)
>>
>> diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
>> index 25b43a8c2b15..1722dae9381a 100644
>> --- a/tools/testing/selftests/Makefile
>> +++ b/tools/testing/selftests/Makefile
>> @@ -1,5 +1,6 @@
>> # SPDX-License-Identifier: GPL-2.0
>> TARGETS = android
>> +TARGETS += arm64
>> TARGETS += bpf
>> TARGETS += breakpoints
>> TARGETS += capabilities
>> diff --git a/tools/testing/selftests/arm64/Makefile b/tools/testing/selftests/arm64/Makefile
>> index a61b2e743e99..cbb2a5a9e3fc 100644
>> --- a/tools/testing/selftests/arm64/Makefile
>> +++ b/tools/testing/selftests/arm64/Makefile
>> @@ -1,11 +1,66 @@
>> # SPDX-License-Identifier: GPL-2.0
>>
>> -# ARCH can be overridden by the user for cross compiling
>> +# When ARCH not overridden for crosscompiling, lookup machine
>> ARCH ?= $(shell uname -m 2>/dev/null || echo not)
>>
>> ifneq (,$(filter $(ARCH),aarch64 arm64))
>> -TEST_GEN_PROGS := tags_test
>> -TEST_PROGS := run_tags_test.sh
>> +SUBTARGETS ?= tags
>> +else
>> +SUBTARGETS :=
>> endif
>>
>> -include ../lib.mk
>> +CFLAGS := -Wall -O2 -g
>> +
>> +# A proper top_srcdir is needed by KSFT(lib.mk)
>> +top_srcdir = $(realpath ../../../../)
>> +
>> +# Additional include paths needed by kselftest.h and local headers
>> +CFLAGS += -I$(top_srcdir)/tools/testing/selftests/
>> +
>> +# Guessing where the Kernel headers could have been installed
>> +# depending on ENV config
>> +ifeq ($(KBUILD_OUTPUT),)
>> +khdr_dir = $(top_srcdir)/usr/include
>> +else
>> +# the KSFT preferred location when KBUILD_OUTPUT is set
>> +khdr_dir = $(KBUILD_OUTPUT)/kselftest/usr/include
>> +endif
>> +
>> +CFLAGS += -I$(khdr_dir)
>> +
>> +export CFLAGS
>> +export top_srcdir
>> +
>> +all:
>> + @for DIR in $(SUBTARGETS); do \
>> + BUILD_TARGET=$(OUTPUT)/$$DIR; \
>> + mkdir -p $$BUILD_TARGET; \
>> + make OUTPUT=$$BUILD_TARGET -C $$DIR $@; \
>> + done
>> +
>> +install: all
>> + @for DIR in $(SUBTARGETS); do \
>> + BUILD_TARGET=$(OUTPUT)/$$DIR; \
>> + make OUTPUT=$$BUILD_TARGET -C $$DIR $@; \
>> + done
>> +
>> +run_tests: all
>> + @for DIR in $(SUBTARGETS); do \
>> + BUILD_TARGET=$(OUTPUT)/$$DIR; \
>> + make OUTPUT=$$BUILD_TARGET -C $$DIR $@; \
>> + done
>> +
>> +# Avoid any output on non arm64 on emit_tests
>> +emit_tests: all
>> + @for DIR in $(SUBTARGETS); do \
>> + BUILD_TARGET=$(OUTPUT)/$$DIR; \
>> + make OUTPUT=$$BUILD_TARGET -C $$DIR $@; \
>> + done
>> +
>> +clean:
>> + @for DIR in $(SUBTARGETS); do \
>> + BUILD_TARGET=$(OUTPUT)/$$DIR; \
>> + make OUTPUT=$$BUILD_TARGET -C $$DIR $@; \
>> + done
>> +
>> +.PHONY: all clean install run_tests emit_tests
>> diff --git a/tools/testing/selftests/arm64/README b/tools/testing/selftests/arm64/README
>> new file mode 100644
>> index 000000000000..cc1e51796fee
>> --- /dev/null
>> +++ b/tools/testing/selftests/arm64/README
>> @@ -0,0 +1,25 @@
>> +KSelfTest ARM64
>> +===============
>> +
>> +- These tests are arm64 specific and so not built or run but just skipped
>> + completely when env-variable ARCH is found to be different than 'arm64'
>> + and `uname -m` reports other than 'aarch64'.
>> +
>> +- Holding true the above, ARM64 KSFT tests can be run within the KSelfTest
>> + framework using standard Linux top-level-makefile targets:
>> +
>> + $ make TARGETS=arm64 kselftest-clean
>> + $ make TARGETS=arm64 kselftest
>> +
>> + or
>> +
>> + $ make -C tools/testing/selftests TARGETS=arm64 \
>> + INSTALL_PATH=<your-installation-path> install
>> +
>> + or, alternatively, only specific arm64/ subtargets can be picked:
>> +
>> + $ make -C tools/testing/selftests TARGETS=arm64 SUBTARGETS="tags signal" \
>> + INSTALL_PATH=<your-installation-path> install
>> +
>> + Further details on building and running KFST can be found in:
>> + Documentation/dev-tools/kselftest.rst
>> diff --git a/tools/testing/selftests/arm64/tags/Makefile b/tools/testing/selftests/arm64/tags/Makefile
>> new file mode 100644
>> index 000000000000..dcc8b0467b68
>> --- /dev/null
>> +++ b/tools/testing/selftests/arm64/tags/Makefile
>> @@ -0,0 +1,6 @@
>> +# SPDX-License-Identifier: GPL-2.0
>> +
>> +TEST_GEN_PROGS := tags_test
>
> This should be TEST_GEN_FILES, since its used by run_tags_test.sh.
> If its TEST_GEN_PROGS it will be added to the script run_kselftest.sh,
> and I don't think thats the intent, even though it looked like that
> before.
>
In fact I saw the tags tests running twice (via ./tags_test and via ./run_tags_test.sh) when called
via run_kselftest.sh....but since it was already like that in the original patch so I did not want to
fix it in the context of this series (where tags tests are simply relocated into their own directory)
I could add a separate fix on top of this series if it could make sense.
Cheers
Cristian
> Cheers,
> Anders
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: dts: imx6dl: SolidRun: add phy node with 100Mb/s max-speed
From: Russell King - ARM Linux admin @ 2019-09-17 15:17 UTC (permalink / raw)
To: tinywrkb
Cc: Mark Rutland, Andrew Lunn, Baruch Siach,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Shawn Guo, Sascha Hauer, open list, Rob Herring, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam, linux-arm-kernel
In-Reply-To: <20190917133942.GR25745@shell.armlinux.org.uk>
On Tue, Sep 17, 2019 at 02:39:43PM +0100, Russell King - ARM Linux admin wrote:
> On Tue, Sep 17, 2019 at 04:32:53PM +0300, tinywrkb wrote:
> > On Tue, Sep 17, 2019 at 02:54:34PM +0200, Andrew Lunn wrote:
> > > On Tue, Sep 17, 2019 at 03:41:01PM +0300, tinywrkb wrote:
> > > > On Sun, Sep 15, 2019 at 03:56:52PM +0200, Andrew Lunn wrote:
> > > > > > Tinywrkb confirmed to me in private communication that revert of
> > > > > > 5502b218e001 fixes Ethernet for him on effected system.
> > > > > >
> > > > > > He also referred me to an old Cubox-i spec that lists 10/100 Ethernet
> > > > > > only for i.MX6 Solo/DualLite variants of Cubox-i. It turns out that
> > > > > > there was a plan to use a different 10/100 PHY for Solo/DualLite
> > > > > > SOMs. This plan never materialized. All SolidRun i.MX6 SOMs use the same
> > > > > > AR8035 PHY that supports 1Gb.
> > > > > >
> > > > > > Commit 5502b218e001 might be triggering a hardware issue on the affected
> > > > > > Cubox-i. I could not reproduce the issue here with Cubox-i and a Dual
> > > > > > SOM variant running v5.3-rc8. I have no Solo/DualLite variant handy at
> > > > > > the moment.
> > > > >
> > > > > Could somebody with an affected device show us the output of ethtool
> > > > > with and without 5502b218e001. Does one show 1G has been negotiated,
> > > > > and the other 100Mbps? If this is true, how does it get 100Mbps
> > > > > without that patch? We are missing a piece of the puzzle.
> > > > >
> > > > > Andrew
> > > >
> > > > linux-test-5.1rc1-a2703de70942-without_bad_commit
> > > >
> > > > Settings for eth0:
> > > > Supported ports: [ TP MII ]
> > > > Supported link modes: 10baseT/Half 10baseT/Full
> > > > 100baseT/Half 100baseT/Full
> > > > 1000baseT/Full
> > >
> > > So this means the local device says it can do 1000Mbps.
> > >
> > >
> > > > Supported pause frame use: Symmetric
> > > > Supports auto-negotiation: Yes
> > > > Supported FEC modes: Not reported
> > > > Advertised link modes: 10baseT/Half 10baseT/Full
> > > > 100baseT/Half 100baseT/Full
> > > > 1000baseT/Full
> > >
> > > The link peer can also do 1000Mbps.
> > >
> > >
> > > > Advertised pause frame use: Symmetric
> > > > Advertised auto-negotiation: Yes
> > > > Advertised FEC modes: Not reported
> > > > Link partner advertised link modes: 10baseT/Half 10baseT/Full
> > > > 100baseT/Half 100baseT/Full
> > > > 1000baseT/Full
> > > > Link partner advertised pause frame use: Symmetric
> > > > Link partner advertised auto-negotiation: Yes
> > > > Link partner advertised FEC modes: Not reported
> > > > Speed: 100Mb/s
> > >
> > > Yet they have decided to do 100Mbps.
> > >
> > > We need to understand Why? The generic PHY driver would not do this on
> > > its own. So i'm thinking something has poked a PHY register with some
> > > value, and this patch is causing it to be over written.
> > >
> > > Please can you use mii-tool -v -v to dump the PHY registers in each
> > > case.
> > >
> > > Thanks
> > > Andrew
> >
> > Here's the output of # mii-tool -v -v eth0
> >
> > * linux-test-5.1rc1-a2703de70942-without_bad_commit
> >
> > Using SIOCGMIIPHY=0x8947
> > eth0: negotiated 100baseTx-FD flow-control, link ok
> > registers for MII PHY 0:
> > 3100 796d 004d d072 15e1 c5e1 000f 0000
> > 0000 0000 0800 0000 0000 0000 0000 a000
> > 0000 0000 0000 f420 082c 0000 04e8 0000
> > 3200 3000 0000 063d 0000 0000 0000 0000
> > product info: vendor 00:13:74, model 7 rev 2
> > basic mode: autonegotiation enabled
> > basic status: autonegotiation complete, link ok
> > capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> > advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
> > link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
>
> This is *not* advertising 1000baseT modes (register 9).
>
> >
> >
> > * linux-test-5.1rc1-5502b218e001-with_bad_commit
> >
> > Using SIOCGMIIPHY=0x8947
> > eth0: negotiated 100baseTx-FD flow-control, link ok
> > registers for MII PHY 0:
> > 3100 796d 004d d072 15e1 c5e1 000d 0000
> > 0000 0000 0800 0000 0000 0000 0000 a000
> > 0000 0000 0000 0000 082c 0000 04e8 0000
> > 3200 3000 0000 063d 0000 0000 0000 0000
> > product info: vendor 00:13:74, model 7 rev 2
> > basic mode: autonegotiation enabled
> > basic status: autonegotiation complete, link ok
> > capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> > advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
> > link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
>
> Neither is this.
>
> However, the kernel and phylib _thinks_ that it is. My guess is
> something has rewritten the PHY registers from userspace, rather
> than using ethtool to change the advertisment. The MAC is still
> trying to operate at 1000Mbps (since that is what phylib resolved)
> yet the link might be actually operating at 100Mbps - but for that
> to happen, we should've seen the link go down and up again.
>
> Odd.
For reference, here I see:
Using SIOCGMIIPHY=0x8947
eth0: negotiated 1000baseT-FD flow-control, link ok
registers for MII PHY 0:
3100 796d 004d d072 15e1 c1e1 000d 0000
0000 0200 3800 0000 0000 0000 0000 a000
0000 0000 0000 0000 082c 0000 04e8 0000
3200 3000 0000 060e 0000 0000 0000 0000
product info: vendor 00:13:74, model 7 rev 2
basic mode: autonegotiation enabled
basic status: autonegotiation complete, link ok
capabilities: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
Note that userspace writing to register 9 (1G settings) will update
the physical PHY's advertisment for 1G speeds, but the kernel's idea
will not be updated, so things will become de-sync'd, and the kernel
_will_ incorrectly determine the speed.
So, are you using mii-tool or mii-diag to change the negotiation
settings, rather than using ethtool?
This is likely the case, as prior to 5502b218e001, we used to read
the advertisment registers afresh each time we evaluate the resulting
link mode. After 5502b218e001, we use the advertisment mask cached
in phydev->advertising, which, looking at phy_mii_ioctl(), will not
be updated if register 9 is written.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] ARM: dts: imx6q: Enable CAN in board DTS
From: Fabio Estevam @ 2019-09-17 15:29 UTC (permalink / raw)
To: Marek Vasut
Cc: Shawn Guo, Ludwig Zenz,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
NXP Linux Team
In-Reply-To: <20190917143714.12876-1-marex@denx.de>
Hi Marek,
On Tue, Sep 17, 2019 at 11:37 AM Marek Vasut <marex@denx.de> wrote:
In the Subject, please make it more specific by stating the board name:
ARM: dts: imx6q-dhcom: Enable CAN
> Move the CAN enablement from SoM DTSi to board DTS, as each board might need
> different CAN configuration. Moreover, disable CAN2 on the PDK2 as it is not
> available on any connector. This also fixes on-SoM SD slot operation, as it
> shares pins with the CAN2.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
Apart from that:
Reviewed-by: Fabio Estevam <festevam@gmail.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 01/11] kselftest: arm64: extend toplevel skeleton Makefile
From: shuah @ 2019-09-17 15:29 UTC (permalink / raw)
To: Cristian Marussi, Anders Roxell
Cc: andreyknvl, linux-kselftest, amit.kachhap, shuah, dave.martin,
linux-arm-kernel
In-Reply-To: <38863e6e-4d6f-b7a6-2add-937fff9e5ef2@arm.com>
On 9/17/19 9:17 AM, Cristian Marussi wrote:
> Hi Anders
>
> thanks for the review.
>
> On 17/09/2019 14:42, Anders Roxell wrote:
>> On 2019-09-10 13:31, Cristian Marussi wrote:
>>> Modify KSFT arm64 toplevel Makefile to maintain arm64 kselftests organized
>>> by subsystem, keeping them into distinct subdirectories under arm64 custom
>>> KSFT directory: tools/testing/selftests/arm64/
>>>
>>> Add to such toplevel Makefile a mechanism to guess the effective location
>>> of Kernel headers as installed by KSFT framework.
>>>
>>> Fit existing arm64 tags kselftest into this new schema moving them into
>>> their own subdirectory (arm64/tags).
>>>
>>> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
>>> ---
>>> Based on:
>>> commit 9ce1263033cd ("selftests, arm64: add a selftest for passing
>>> tagged pointers to kernel")
>>> ---
>>> v5 --> v6
>>> - using realpath to avoid passing down relative paths
>>> - fix commit msg & Copyright
>>> - removed unneded Makefile export
>>> - added SUBTARGETS specification, to allow building specific only some
>>> arm64 test subsystems
>>> v4 --> v5
>>> - rebased on arm64/for-next/core
>>> - merged this patch with KSFT arm64 tags patch, while moving the latter
>>> into its own subdir
>>> - moved kernel header includes search mechanism from KSFT arm64
>>> SIGNAL Makefile
>>> - export proper top_srcdir ENV for lib.mk
>>> v3 --> v4
>>> - comment reword
>>> - simplified documentation in README
>>> - dropped README about standalone
>>> ---
>>> tools/testing/selftests/Makefile | 1 +
>>> tools/testing/selftests/arm64/Makefile | 63 +++++++++++++++++--
>>> tools/testing/selftests/arm64/README | 25 ++++++++
>>> tools/testing/selftests/arm64/tags/Makefile | 6 ++
>>> .../arm64/{ => tags}/run_tags_test.sh | 0
>>> .../selftests/arm64/{ => tags}/tags_test.c | 0
>>> 6 files changed, 91 insertions(+), 4 deletions(-)
>>> create mode 100644 tools/testing/selftests/arm64/README
>>> create mode 100644 tools/testing/selftests/arm64/tags/Makefile
>>> rename tools/testing/selftests/arm64/{ => tags}/run_tags_test.sh (100%)
>>> rename tools/testing/selftests/arm64/{ => tags}/tags_test.c (100%)
>>>
>>> diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
>>> index 25b43a8c2b15..1722dae9381a 100644
>>> --- a/tools/testing/selftests/Makefile
>>> +++ b/tools/testing/selftests/Makefile
>>> @@ -1,5 +1,6 @@
>>> # SPDX-License-Identifier: GPL-2.0
>>> TARGETS = android
>>> +TARGETS += arm64
>>> TARGETS += bpf
>>> TARGETS += breakpoints
>>> TARGETS += capabilities
>>> diff --git a/tools/testing/selftests/arm64/Makefile b/tools/testing/selftests/arm64/Makefile
>>> index a61b2e743e99..cbb2a5a9e3fc 100644
>>> --- a/tools/testing/selftests/arm64/Makefile
>>> +++ b/tools/testing/selftests/arm64/Makefile
>>> @@ -1,11 +1,66 @@
>>> # SPDX-License-Identifier: GPL-2.0
>>>
>>> -# ARCH can be overridden by the user for cross compiling
>>> +# When ARCH not overridden for crosscompiling, lookup machine
>>> ARCH ?= $(shell uname -m 2>/dev/null || echo not)
>>>
>>> ifneq (,$(filter $(ARCH),aarch64 arm64))
>>> -TEST_GEN_PROGS := tags_test
>>> -TEST_PROGS := run_tags_test.sh
>>> +SUBTARGETS ?= tags
>>> +else
>>> +SUBTARGETS :=
>>> endif
>>>
>>> -include ../lib.mk
>>> +CFLAGS := -Wall -O2 -g
>>> +
>>> +# A proper top_srcdir is needed by KSFT(lib.mk)
>>> +top_srcdir = $(realpath ../../../../)
>>> +
>>> +# Additional include paths needed by kselftest.h and local headers
>>> +CFLAGS += -I$(top_srcdir)/tools/testing/selftests/
>>> +
>>> +# Guessing where the Kernel headers could have been installed
>>> +# depending on ENV config
>>> +ifeq ($(KBUILD_OUTPUT),)
>>> +khdr_dir = $(top_srcdir)/usr/include
>>> +else
>>> +# the KSFT preferred location when KBUILD_OUTPUT is set
>>> +khdr_dir = $(KBUILD_OUTPUT)/kselftest/usr/include
>>> +endif
>>> +
>>> +CFLAGS += -I$(khdr_dir)
>>> +
>>> +export CFLAGS
>>> +export top_srcdir
>>> +
>>> +all:
>>> + @for DIR in $(SUBTARGETS); do \
>>> + BUILD_TARGET=$(OUTPUT)/$$DIR; \
>>> + mkdir -p $$BUILD_TARGET; \
>>> + make OUTPUT=$$BUILD_TARGET -C $$DIR $@; \
>>> + done
>>> +
>>> +install: all
>>> + @for DIR in $(SUBTARGETS); do \
>>> + BUILD_TARGET=$(OUTPUT)/$$DIR; \
>>> + make OUTPUT=$$BUILD_TARGET -C $$DIR $@; \
>>> + done
>>> +
>>> +run_tests: all
>>> + @for DIR in $(SUBTARGETS); do \
>>> + BUILD_TARGET=$(OUTPUT)/$$DIR; \
>>> + make OUTPUT=$$BUILD_TARGET -C $$DIR $@; \
>>> + done
>>> +
>>> +# Avoid any output on non arm64 on emit_tests
>>> +emit_tests: all
>>> + @for DIR in $(SUBTARGETS); do \
>>> + BUILD_TARGET=$(OUTPUT)/$$DIR; \
>>> + make OUTPUT=$$BUILD_TARGET -C $$DIR $@; \
>>> + done
>>> +
>>> +clean:
>>> + @for DIR in $(SUBTARGETS); do \
>>> + BUILD_TARGET=$(OUTPUT)/$$DIR; \
>>> + make OUTPUT=$$BUILD_TARGET -C $$DIR $@; \
>>> + done
>>> +
>>> +.PHONY: all clean install run_tests emit_tests
>>> diff --git a/tools/testing/selftests/arm64/README b/tools/testing/selftests/arm64/README
>>> new file mode 100644
>>> index 000000000000..cc1e51796fee
>>> --- /dev/null
>>> +++ b/tools/testing/selftests/arm64/README
>>> @@ -0,0 +1,25 @@
>>> +KSelfTest ARM64
>>> +===============
>>> +
>>> +- These tests are arm64 specific and so not built or run but just skipped
>>> + completely when env-variable ARCH is found to be different than 'arm64'
>>> + and `uname -m` reports other than 'aarch64'.
>>> +
>>> +- Holding true the above, ARM64 KSFT tests can be run within the KSelfTest
>>> + framework using standard Linux top-level-makefile targets:
>>> +
>>> + $ make TARGETS=arm64 kselftest-clean
>>> + $ make TARGETS=arm64 kselftest
>>> +
>>> + or
>>> +
>>> + $ make -C tools/testing/selftests TARGETS=arm64 \
>>> + INSTALL_PATH=<your-installation-path> install
>>> +
>>> + or, alternatively, only specific arm64/ subtargets can be picked:
>>> +
>>> + $ make -C tools/testing/selftests TARGETS=arm64 SUBTARGETS="tags signal" \
>>> + INSTALL_PATH=<your-installation-path> install
>>> +
>>> + Further details on building and running KFST can be found in:
>>> + Documentation/dev-tools/kselftest.rst
>>> diff --git a/tools/testing/selftests/arm64/tags/Makefile b/tools/testing/selftests/arm64/tags/Makefile
>>> new file mode 100644
>>> index 000000000000..dcc8b0467b68
>>> --- /dev/null
>>> +++ b/tools/testing/selftests/arm64/tags/Makefile
>>> @@ -0,0 +1,6 @@
>>> +# SPDX-License-Identifier: GPL-2.0
>>> +
>>> +TEST_GEN_PROGS := tags_test
>>
>> This should be TEST_GEN_FILES, since its used by run_tags_test.sh.
>> If its TEST_GEN_PROGS it will be added to the script run_kselftest.sh,
>> and I don't think thats the intent, even though it looked like that
>> before.
>>
>
> In fact I saw the tags tests running twice (via ./tags_test and via ./run_tags_test.sh) when called
> via run_kselftest.sh....but since it was already like that in the original patch so I did not want to
> fix it in the context of this series (where tags tests are simply relocated into their own directory)
>
> I could add a separate fix on top of this series if it could make sense.
>
We are still in review phase I would think. It would make sense to fix
the original patch and not as a separate fix patch.
thanks,
-- Shuah
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: imx6q: Add ethernet PHY power GPIO
From: Fabio Estevam @ 2019-09-17 15:30 UTC (permalink / raw)
To: Marek Vasut
Cc: Shawn Guo, Ludwig Zenz,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
NXP Linux Team
In-Reply-To: <20190917143714.12876-2-marex@denx.de>
Hi Marek,
On Tue, Sep 17, 2019 at 11:37 AM Marek Vasut <marex@denx.de> wrote:
> diff --git a/arch/arm/boot/dts/imx6q-dhcom-som.dtsi b/arch/arm/boot/dts/imx6q-dhcom-som.dtsi
> index 845cfad99bf9..687caedf0784 100644
> --- a/arch/arm/boot/dts/imx6q-dhcom-som.dtsi
> +++ b/arch/arm/boot/dts/imx6q-dhcom-som.dtsi
> @@ -86,6 +86,7 @@
> pinctrl-0 = <&pinctrl_enet_100M>;
> phy-mode = "rmii";
> phy-handle = <ðphy0>;
> + power-gpios = <&gpio1 7 GPIO_ACTIVE_LOW>;
This is not a documented property.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: dts: imx6dl: SolidRun: add phy node with 100Mb/s max-speed
From: Russell King - ARM Linux admin @ 2019-09-17 15:30 UTC (permalink / raw)
To: tinywrkb
Cc: Mark Rutland, Andrew Lunn, Baruch Siach,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Fabio Estevam, Sascha Hauer, open list, Rob Herring,
NXP Linux Team, Pengutronix Kernel Team, Shawn Guo,
linux-arm-kernel
In-Reply-To: <20190917151707.GV25745@shell.armlinux.org.uk>
On Tue, Sep 17, 2019 at 04:17:07PM +0100, Russell King - ARM Linux admin wrote:
> On Tue, Sep 17, 2019 at 02:39:43PM +0100, Russell King - ARM Linux admin wrote:
> > On Tue, Sep 17, 2019 at 04:32:53PM +0300, tinywrkb wrote:
> > > On Tue, Sep 17, 2019 at 02:54:34PM +0200, Andrew Lunn wrote:
> > > > On Tue, Sep 17, 2019 at 03:41:01PM +0300, tinywrkb wrote:
> > > > > On Sun, Sep 15, 2019 at 03:56:52PM +0200, Andrew Lunn wrote:
> > > > > > > Tinywrkb confirmed to me in private communication that revert of
> > > > > > > 5502b218e001 fixes Ethernet for him on effected system.
> > > > > > >
> > > > > > > He also referred me to an old Cubox-i spec that lists 10/100 Ethernet
> > > > > > > only for i.MX6 Solo/DualLite variants of Cubox-i. It turns out that
> > > > > > > there was a plan to use a different 10/100 PHY for Solo/DualLite
> > > > > > > SOMs. This plan never materialized. All SolidRun i.MX6 SOMs use the same
> > > > > > > AR8035 PHY that supports 1Gb.
> > > > > > >
> > > > > > > Commit 5502b218e001 might be triggering a hardware issue on the affected
> > > > > > > Cubox-i. I could not reproduce the issue here with Cubox-i and a Dual
> > > > > > > SOM variant running v5.3-rc8. I have no Solo/DualLite variant handy at
> > > > > > > the moment.
> > > > > >
> > > > > > Could somebody with an affected device show us the output of ethtool
> > > > > > with and without 5502b218e001. Does one show 1G has been negotiated,
> > > > > > and the other 100Mbps? If this is true, how does it get 100Mbps
> > > > > > without that patch? We are missing a piece of the puzzle.
> > > > > >
> > > > > > Andrew
> > > > >
> > > > > linux-test-5.1rc1-a2703de70942-without_bad_commit
> > > > >
> > > > > Settings for eth0:
> > > > > Supported ports: [ TP MII ]
> > > > > Supported link modes: 10baseT/Half 10baseT/Full
> > > > > 100baseT/Half 100baseT/Full
> > > > > 1000baseT/Full
> > > >
> > > > So this means the local device says it can do 1000Mbps.
> > > >
> > > >
> > > > > Supported pause frame use: Symmetric
> > > > > Supports auto-negotiation: Yes
> > > > > Supported FEC modes: Not reported
> > > > > Advertised link modes: 10baseT/Half 10baseT/Full
> > > > > 100baseT/Half 100baseT/Full
> > > > > 1000baseT/Full
> > > >
> > > > The link peer can also do 1000Mbps.
> > > >
> > > >
> > > > > Advertised pause frame use: Symmetric
> > > > > Advertised auto-negotiation: Yes
> > > > > Advertised FEC modes: Not reported
> > > > > Link partner advertised link modes: 10baseT/Half 10baseT/Full
> > > > > 100baseT/Half 100baseT/Full
> > > > > 1000baseT/Full
> > > > > Link partner advertised pause frame use: Symmetric
> > > > > Link partner advertised auto-negotiation: Yes
> > > > > Link partner advertised FEC modes: Not reported
> > > > > Speed: 100Mb/s
> > > >
> > > > Yet they have decided to do 100Mbps.
> > > >
> > > > We need to understand Why? The generic PHY driver would not do this on
> > > > its own. So i'm thinking something has poked a PHY register with some
> > > > value, and this patch is causing it to be over written.
> > > >
> > > > Please can you use mii-tool -v -v to dump the PHY registers in each
> > > > case.
> > > >
> > > > Thanks
> > > > Andrew
> > >
> > > Here's the output of # mii-tool -v -v eth0
> > >
> > > * linux-test-5.1rc1-a2703de70942-without_bad_commit
> > >
> > > Using SIOCGMIIPHY=0x8947
> > > eth0: negotiated 100baseTx-FD flow-control, link ok
> > > registers for MII PHY 0:
> > > 3100 796d 004d d072 15e1 c5e1 000f 0000
> > > 0000 0000 0800 0000 0000 0000 0000 a000
> > > 0000 0000 0000 f420 082c 0000 04e8 0000
> > > 3200 3000 0000 063d 0000 0000 0000 0000
> > > product info: vendor 00:13:74, model 7 rev 2
> > > basic mode: autonegotiation enabled
> > > basic status: autonegotiation complete, link ok
> > > capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> > > advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
> > > link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
> >
> > This is *not* advertising 1000baseT modes (register 9).
> >
> > >
> > >
> > > * linux-test-5.1rc1-5502b218e001-with_bad_commit
> > >
> > > Using SIOCGMIIPHY=0x8947
> > > eth0: negotiated 100baseTx-FD flow-control, link ok
> > > registers for MII PHY 0:
> > > 3100 796d 004d d072 15e1 c5e1 000d 0000
> > > 0000 0000 0800 0000 0000 0000 0000 a000
> > > 0000 0000 0000 0000 082c 0000 04e8 0000
> > > 3200 3000 0000 063d 0000 0000 0000 0000
> > > product info: vendor 00:13:74, model 7 rev 2
> > > basic mode: autonegotiation enabled
> > > basic status: autonegotiation complete, link ok
> > > capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> > > advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
> > > link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
> >
> > Neither is this.
> >
> > However, the kernel and phylib _thinks_ that it is. My guess is
> > something has rewritten the PHY registers from userspace, rather
> > than using ethtool to change the advertisment. The MAC is still
> > trying to operate at 1000Mbps (since that is what phylib resolved)
> > yet the link might be actually operating at 100Mbps - but for that
> > to happen, we should've seen the link go down and up again.
> >
> > Odd.
>
> For reference, here I see:
>
> Using SIOCGMIIPHY=0x8947
> eth0: negotiated 1000baseT-FD flow-control, link ok
> registers for MII PHY 0:
> 3100 796d 004d d072 15e1 c1e1 000d 0000
> 0000 0200 3800 0000 0000 0000 0000 a000
> 0000 0000 0000 0000 082c 0000 04e8 0000
> 3200 3000 0000 060e 0000 0000 0000 0000
> product info: vendor 00:13:74, model 7 rev 2
> basic mode: autonegotiation enabled
> basic status: autonegotiation complete, link ok
> capabilities: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> advertising: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
> link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
>
> Note that userspace writing to register 9 (1G settings) will update
> the physical PHY's advertisment for 1G speeds, but the kernel's idea
> will not be updated, so things will become de-sync'd, and the kernel
> _will_ incorrectly determine the speed.
>
> So, are you using mii-tool or mii-diag to change the negotiation
> settings, rather than using ethtool?
>
> This is likely the case, as prior to 5502b218e001, we used to read
> the advertisment registers afresh each time we evaluate the resulting
> link mode. After 5502b218e001, we use the advertisment mask cached
> in phydev->advertising, which, looking at phy_mii_ioctl(), will not
> be updated if register 9 is written.
Please try this patch - I haven't written a commit message for it yet,
it's just to prove the above point.
Thanks.
drivers/net/phy/phy.c | 5 +++++
include/linux/mii.h | 9 +++++++++
2 files changed, 14 insertions(+)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 7af390d8bbdb..068a08a50064 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -458,6 +458,11 @@ int phy_mii_ioctl(struct phy_device *phydev, struct ifreq *ifr, int cmd)
val);
change_autoneg = true;
break;
+ case MII_CTRL1000:
+ mii_ctrl1000_mod_linkmode_adv_t(phydev->advertising,
+ val);
+ change_autoneg = true;
+ break;
default:
/* do nothing */
break;
diff --git a/include/linux/mii.h b/include/linux/mii.h
index 5cd824c1c0ca..1249d32dbd63 100644
--- a/include/linux/mii.h
+++ b/include/linux/mii.h
@@ -455,6 +455,15 @@ static inline void mii_lpa_mod_linkmode_lpa_t(unsigned long *lp_advertising,
lp_advertising, lpa & LPA_LPACK);
}
+static inline void mii_ctrl1000_mod_linkmode_adv_t(unsigned long *advertising,
+ u32 ctrl1000)
+{
+ linkmode_mod_bit(ETHTOOL_LINK_MODE_1000baseT_Half_BIT, advertising,
+ ctrl1000 & ADVERTISE_1000HALF);
+ linkmode_mod_bit(ETHTOOL_LINK_MODE_1000baseT_Full_BIT, advertising,
+ ctrl1000 & ADVERTISE_1000FULL);
+}
+
/**
* linkmode_adv_to_lcl_adv_t
* @advertising:pointer to linkmode advertising
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Propagating audio properties along the audio path
From: Marc Gonzalez @ 2019-09-17 15:33 UTC (permalink / raw)
To: alsa-devel; +Cc: Takashi Iwai, Linux ARM, Jaroslav Kysela
Hello everyone,
Disclaimer: I've never worked in the sound/ layer, and it is possible that
some of my questions are silly or obvious.
Basically, I'm trying to implement some form of eARC(*) on an arm64 SoC.
(*) enhanced Audio Return Channel (from HDMI 2.1)
The setup looks like this:
A = Some kind of audio source, typically a TV or game console
B = The arm64 SoC, equipped with some nice speakers
HDMI
A ------> B
If we look inside B, we actually have
B1 = an eARC receiver (input = HDMI, output = I2S)
B2 = an audio DSP (input = I2S, output = speakers)
I2S ?
B1 -----> B2 -----> speakers
If I read the standard right, B is supposed to advertise which audio formats
it supports, and A is supposed to pick "the best". For the sake of argument,
let's say A picks "PCM, 48 kHz, 8 channels, 16b".
At some point, B receives audio packets, parses the Channel Status, and
determines that A is sending "PCM, 48 kHz, 8 channels, 16b". The driver
then configures the I2S link, and forwards the audio stream over I2S to
the DSP.
QUESTION_1:
How is the DSP supposed to "learn" the properties of the audio stream?
(AFAIU, they're not embedded in the data, so there must be some side-channel?)
I assume the driver of B1 is supposed to propagate the info to the driver of B2?
(Via some call-backs? By calling a function in B2?)
QUESTION_2:
Does it ever make sense for B2 to ask B1 to change the audio properties?
(Not sure if B1 is even allowed to renegotiate.)
Regards.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V2] ARM: dts: imx6q-dhcom: Enable CAN in board DTS
From: Marek Vasut @ 2019-09-17 15:35 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Shawn Guo, Fabio Estevam, NXP Linux Team,
Ludwig Zenz
Move the CAN enablement from SoM DTSi to board DTS, as each board might need
different CAN configuration. Moreover, disable CAN2 on the PDK2 as it is not
available on any connector. This also fixes on-SoM SD slot operation, as it
shares pins with the CAN2.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Ludwig Zenz <lzenz@dh-electronics.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: NXP Linux Team <linux-imx@nxp.com>
To: linux-arm-kernel@lists.infradead.org
---
V2: Add board name to subject
---
arch/arm/boot/dts/imx6q-dhcom-pdk2.dts | 8 ++++++++
arch/arm/boot/dts/imx6q-dhcom-som.dtsi | 2 --
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q-dhcom-pdk2.dts b/arch/arm/boot/dts/imx6q-dhcom-pdk2.dts
index 9c61e3be2d9a..5219553df1e7 100644
--- a/arch/arm/boot/dts/imx6q-dhcom-pdk2.dts
+++ b/arch/arm/boot/dts/imx6q-dhcom-pdk2.dts
@@ -43,6 +43,14 @@
status = "okay";
};
+&can1 {
+ status = "okay";
+};
+
+&can2 {
+ status = "disabled";
+};
+
&hdmi {
ddc-i2c-bus = <&i2c2>;
status = "okay";
diff --git a/arch/arm/boot/dts/imx6q-dhcom-som.dtsi b/arch/arm/boot/dts/imx6q-dhcom-som.dtsi
index 387801dde02e..845cfad99bf9 100644
--- a/arch/arm/boot/dts/imx6q-dhcom-som.dtsi
+++ b/arch/arm/boot/dts/imx6q-dhcom-som.dtsi
@@ -51,13 +51,11 @@
&can1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_flexcan1>;
- status = "okay";
};
&can2 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_flexcan2>;
- status = "okay";
};
&ecspi1 {
--
2.23.0.rc1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 00/23] mtd: spi-nor: Quad Enable and (un)lock methods
From: Tudor.Ambarus @ 2019-09-17 15:54 UTC (permalink / raw)
To: vigneshr, boris.brezillon, marek.vasut, miquel.raynal, richard,
linux-mtd
Cc: linux-aspeed, Tudor.Ambarus, andrew, linux-kernel, vz,
linux-mediatek, joel, matthias.bgg, computersforpeace, dwmw2,
linux-arm-kernel
From: Tudor Ambarus <tudor.ambarus@microchip.com>
Patches 1 - 14 are just clean up patches for the Flash Register
Operations.
Patches 15 - 21 deal with the Quad Enable and the (un)lock methods.
Fixed the clearing of QE bit on (un)lock() operations. Reworked the
Quad Enable methods and the disabling of the block write protection
at power-up.
Patch 22 adds Global Block Unlock support as an optimization for
unlocking the entire memory array. Patch 23 uses it in sst26vf064b.
This is just compile tested, I don't have a relevant spansion-like
flash memory to test the (un)lock() methods.
The patch set can be tested using mtd-utils:
1/ do a read-erase-write-read-back test immediately after boot, to check
the spi_nor_unlock_all() method
mtd_debug read /dev/mtd-yours offset size read-file
hexdump read-file
mtd_debug erase /dev/mtd-yours offset size
dd if=/dev/urandom of=write-file bs=please-choose count=please-choose
mtd_debug write /dev/mtd-yours offset write-file-size write-file
mtd_debug read /dev/mtd-yours offset write-file-size read-file
sha1sum read-file write-file
2/ lock flash then try to erase/write it, to see if the lock works
flash_lock /dev/mtd-yours offset block-count
read-erase/write-read-back test
3/ unlock flash and do a read-erase-write-read-back to check if the QE
bit was not cleared.
Thanks,
ta
Tudor Ambarus (23):
mtd: spi-nor: hisi-sfc: Drop nor->erase NULL assignment
mtd: spi-nor: Introduce 'struct spi_nor_controller_ops'
mtd: spi-nor: cadence-quadspi: Fix cqspi_command_read() definition
mtd: spi-nor: Rename nor->params to nor->flash
mtd: spi-nor: Rework read_sr()
mtd: spi-nor: Rework read_fsr()
mtd: spi-nor: Rework read_cr()
mtd: spi-nor: Rework write_enable/disable()
mtd: spi-nor: Fix retlen handling in sst_write()
mtd: spi-nor: Rework write_sr()
mtd: spi-nor: Rework spi_nor_read/write_sr2()
mtd: spi-nor: Report error in spi_nor_xread_sr()
mtd: spi-nor: Void return type for spi_nor_clear_sr/fsr()
mtd: spi-nor: Drop duplicated new line
mtd: spi-nor: Drop spansion_quad_enable()
mtd: spi-nor: Fix errno on quad_enable methods
mtd: spi-nor: Fix clearing of QE bit on lock()/unlock()
mtd: spi-nor: Rework macronix_quad_enable()
mtd: spi-nor: Rework spansion(_no)_read_cr_quad_enable()
mtd: spi-nor: Update sr2_bit7_quad_enable()
mtd: spi-nor: Rework the disabling of block write protection
mtd: spi-nor: Add Global Block Unlock support
mtd: spi-nor: Unlock global block protection on sst26vf064b
drivers/mtd/spi-nor/aspeed-smc.c | 23 +-
drivers/mtd/spi-nor/cadence-quadspi.c | 54 +-
drivers/mtd/spi-nor/hisi-sfc.c | 23 +-
drivers/mtd/spi-nor/intel-spi.c | 24 +-
drivers/mtd/spi-nor/mtk-quadspi.c | 25 +-
drivers/mtd/spi-nor/nxp-spifi.c | 23 +-
drivers/mtd/spi-nor/spi-nor.c | 1697 ++++++++++++++++++---------------
include/linux/mtd/spi-nor.h | 75 +-
8 files changed, 1050 insertions(+), 894 deletions(-)
--
2.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 01/23] mtd: spi-nor: hisi-sfc: Drop nor->erase NULL assignment
From: Tudor.Ambarus @ 2019-09-17 15:54 UTC (permalink / raw)
To: vigneshr, boris.brezillon, marek.vasut, miquel.raynal, richard,
linux-mtd
Cc: linux-aspeed, Tudor.Ambarus, andrew, linux-kernel, vz,
linux-mediatek, joel, matthias.bgg, computersforpeace, dwmw2,
linux-arm-kernel
In-Reply-To: <20190917155426.7432-1-tudor.ambarus@microchip.com>
From: Tudor Ambarus <tudor.ambarus@microchip.com>
The pointer to 'struct spi_nor' is kzalloc'ed above in the code.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
---
drivers/mtd/spi-nor/hisi-sfc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/hisi-sfc.c b/drivers/mtd/spi-nor/hisi-sfc.c
index 6dac9dd8bf42..c99ed9cdbf9c 100644
--- a/drivers/mtd/spi-nor/hisi-sfc.c
+++ b/drivers/mtd/spi-nor/hisi-sfc.c
@@ -364,7 +364,6 @@ static int hisi_spi_nor_register(struct device_node *np,
nor->write_reg = hisi_spi_nor_write_reg;
nor->read = hisi_spi_nor_read;
nor->write = hisi_spi_nor_write;
- nor->erase = NULL;
ret = spi_nor_scan(nor, NULL, &hwcaps);
if (ret)
return ret;
--
2.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 03/23] mtd: spi-nor: cadence-quadspi: Fix cqspi_command_read() definition
From: Tudor.Ambarus @ 2019-09-17 15:54 UTC (permalink / raw)
To: vigneshr, boris.brezillon, marek.vasut, miquel.raynal, richard,
linux-mtd
Cc: linux-aspeed, Tudor.Ambarus, andrew, linux-kernel, vz,
linux-mediatek, joel, matthias.bgg, computersforpeace, dwmw2,
linux-arm-kernel
In-Reply-To: <20190917155426.7432-1-tudor.ambarus@microchip.com>
From: Tudor Ambarus <tudor.ambarus@microchip.com>
n_tx was never used, drop it. Replace 'const u8 *txbuf' with 'u8 opcode',
to comply with the SPI NOR int (*read_reg)() method. The 'const'
qualifier has no meaning for parameters passed by value, drop it.
Going furher, the opcode was passed to cqspi_calc_rdreg() and never used,
drop it.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
---
drivers/mtd/spi-nor/cadence-quadspi.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c b/drivers/mtd/spi-nor/cadence-quadspi.c
index ebda612641a4..22008fecd326 100644
--- a/drivers/mtd/spi-nor/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -285,7 +285,7 @@ static irqreturn_t cqspi_irq_handler(int this_irq, void *dev)
return IRQ_HANDLED;
}
-static unsigned int cqspi_calc_rdreg(struct spi_nor *nor, const u8 opcode)
+static unsigned int cqspi_calc_rdreg(struct spi_nor *nor)
{
struct cqspi_flash_pdata *f_pdata = nor->priv;
u32 rdreg = 0;
@@ -354,8 +354,7 @@ static int cqspi_exec_flash_cmd(struct cqspi_st *cqspi, unsigned int reg)
return cqspi_wait_idle(cqspi);
}
-static int cqspi_command_read(struct spi_nor *nor,
- const u8 *txbuf, const unsigned n_tx,
+static int cqspi_command_read(struct spi_nor *nor, u8 opcode,
u8 *rxbuf, size_t n_rx)
{
struct cqspi_flash_pdata *f_pdata = nor->priv;
@@ -373,9 +372,9 @@ static int cqspi_command_read(struct spi_nor *nor,
return -EINVAL;
}
- reg = txbuf[0] << CQSPI_REG_CMDCTRL_OPCODE_LSB;
+ reg = opcode << CQSPI_REG_CMDCTRL_OPCODE_LSB;
- rdreg = cqspi_calc_rdreg(nor, txbuf[0]);
+ rdreg = cqspi_calc_rdreg(nor);
writel(rdreg, reg_base + CQSPI_REG_RD_INSTR);
reg |= (0x1 << CQSPI_REG_CMDCTRL_RD_EN_LSB);
@@ -471,7 +470,7 @@ static int cqspi_read_setup(struct spi_nor *nor)
unsigned int reg;
reg = nor->read_opcode << CQSPI_REG_RD_INSTR_OPCODE_LSB;
- reg |= cqspi_calc_rdreg(nor, nor->read_opcode);
+ reg |= cqspi_calc_rdreg(nor);
/* Setup dummy clock cycles */
dummy_clk = nor->read_dummy;
@@ -604,7 +603,7 @@ static int cqspi_write_setup(struct spi_nor *nor)
/* Set opcode. */
reg = nor->program_opcode << CQSPI_REG_WR_INSTR_OPCODE_LSB;
writel(reg, reg_base + CQSPI_REG_WR_INSTR);
- reg = cqspi_calc_rdreg(nor, nor->program_opcode);
+ reg = cqspi_calc_rdreg(nor);
writel(reg, reg_base + CQSPI_REG_RD_INSTR);
reg = readl(reg_base + CQSPI_REG_SIZE);
@@ -1087,7 +1086,7 @@ static int cqspi_read_reg(struct spi_nor *nor, u8 opcode, u8 *buf, size_t len)
ret = cqspi_set_protocol(nor, 0);
if (!ret)
- ret = cqspi_command_read(nor, &opcode, 1, buf, len);
+ ret = cqspi_command_read(nor, opcode, buf, len);
return ret;
}
--
2.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
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