* [PATCH] PCI: iproc: fix kernel crash if dev->of_node not defined
From: Ray Jui @ 2017-01-13 0:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6891f43f-25e7-1411-800e-97e6788f2f27@gmail.com>
Hi Florian,
On 1/12/2017 4:22 PM, Florian Fainelli wrote:
> On 01/12/2017 04:20 PM, Abylay Ospan wrote:
>> pcie->dev->of_node not always defined (NULL) and can cause crash:
>>
>> [ 19.053195] Unable to handle kernel NULL pointer dereference at
>> virtual address 00000020
>> [<c0b0370c>] (of_n_addr_cells) from [<c06599c4>]
>> (iproc_pcie_setup+0x30c/0xce0)
>>
>> this patch adds sanity check to prevent crash.
>
> Humm, how can it not be defined based on your earlier comment that you
> are using this on NSP which is Device Tree exclusively? I would agree if
> this was seen on e.g: MIPS/BCMA (47xx).
I thought Abylay mentioned:
"Tested on Broadcom NorthStar machine ('Edgecore ECW7220-L') with two
PCIe wifi
adapters (b43 BCM4331 and ath10k QCA988X)."
That is a NorthStar device which is BCMA based?
>
>>
>> Signed-off-by: Abylay Ospan <aospan@netup.ru>
>> ---
>> drivers/pci/host/pcie-iproc.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
>> index 3ebc025..f2836a9 100644
>> --- a/drivers/pci/host/pcie-iproc.c
>> +++ b/drivers/pci/host/pcie-iproc.c
>> @@ -952,6 +952,9 @@ static int pci_dma_range_parser_init(struct of_pci_range_parser *parser,
>> const int na = 3, ns = 2;
>> int rlen;
>>
>> + if (!node)
>> + return -ENOENT;
>> +
>> parser->node = node;
>> parser->pna = of_n_addr_cells(node);
>> parser->np = parser->pna + na + ns;
>>
>
>
^ permalink raw reply
* [PATCH] ARM64: dts: meson-gxbb-odroidc2: fix GbE tx link breakage
From: Kevin Hilman @ 2017-01-13 0:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482319894-656-1-git-send-email-jbrunet@baylibre.com>
Jerome Brunet <jbrunet@baylibre.com> writes:
> OdroidC2 GbE link breaks under heavy tx transfer. This happens even if the
> MAC does not enable Energy Efficient Ethernet (No Low Power state Idle on
> the Tx path). The problem seems to come from the phy Rx path, entering the
> LPI state.
>
> Disabling EEE advertisement on the phy prevent this feature to be
> negociated with the link partner and solve the issue.
>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
>
> This patch is based on Linus recent master branch [0]
> This patch depends on the series [1] which has been merged in this branch.
>
> 0: ba6d973f78eb ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net")
> 1: http://lkml.kernel.org/r/1480326409-25419-1-git-send-email-jbrunet at baylibre.com
> Fix integration of eee-broken-modes
>
> arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> index 238fbeacd330..d8933e9e9a5a 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> @@ -147,6 +147,18 @@
> status = "okay";
> pinctrl-0 = <ð_rgmii_pins>;
> pinctrl-names = "default";
> + phy-handle = <ð_phy0>;
> +
> + mdio {
> + compatible = "snps,dwmac-mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + eth_phy0: ethernet-phy at 0 {
> + reg = <0>;
> + eee-broken-1000t;
> + };
> + };
There's already an MDIO node in the meson-gx.dtsi (using the same
compatible), shouldn't you just override that and add the new
properties?
What would make things easier is if the names were like Martin used in
his reset patch, so that when I merge them together it's not a major
conflict.
Thanks,
Kevin
[1] https://patchwork.kernel.org/patch/9459409/
^ permalink raw reply
* [PATCH v2 7/7] uapi: export all headers under uapi directories
From: Jeff Epler @ 2017-01-13 1:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9d68af8a-a609-d7b1-58a9-f1155313b077@6wind.com>
On Thu, Jan 12, 2017 at 05:32:09PM +0100, Nicolas Dichtel wrote:
> What I was trying to say is that I export those directories like other are.
> Removing those files is not related to that series.
Perhaps the correct solution is to only copy files matching "*.h" to
reduce the risk of copying files incidentally created by kbuild but
which shouldn't be installed as uapi headers.
jeff
^ permalink raw reply
* [PATCH] PCI: iproc: fix kernel crash if dev->of_node not defined
From: Florian Fainelli @ 2017-01-13 1:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e5301de6-9a6c-7deb-4ff7-ccd462c4381e@broadcom.com>
On 01/12/2017 04:48 PM, Ray Jui wrote:
> Hi Florian,
>
> On 1/12/2017 4:22 PM, Florian Fainelli wrote:
>> On 01/12/2017 04:20 PM, Abylay Ospan wrote:
>>> pcie->dev->of_node not always defined (NULL) and can cause crash:
>>>
>>> [ 19.053195] Unable to handle kernel NULL pointer dereference at
>>> virtual address 00000020
>>> [<c0b0370c>] (of_n_addr_cells) from [<c06599c4>]
>>> (iproc_pcie_setup+0x30c/0xce0)
>>>
>>> this patch adds sanity check to prevent crash.
>>
>> Humm, how can it not be defined based on your earlier comment that you
>> are using this on NSP which is Device Tree exclusively? I would agree if
>> this was seen on e.g: MIPS/BCMA (47xx).
>
> I thought Abylay mentioned:
>
> "Tested on Broadcom NorthStar machine ('Edgecore ECW7220-L') with two
> PCIe wifi
> adapters (b43 BCM4331 and ath10k QCA988X)."
>
> That is a NorthStar device which is BCMA based?
Still, upstream Linux support for Northstar is Device Tree, and BCMA bus
should fill in of_nodes accordingly, if not, that's a bug that must be
fixed at the BCMA layer.
>
>>
>>>
>>> Signed-off-by: Abylay Ospan <aospan@netup.ru>
>>> ---
>>> drivers/pci/host/pcie-iproc.c | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
>>> index 3ebc025..f2836a9 100644
>>> --- a/drivers/pci/host/pcie-iproc.c
>>> +++ b/drivers/pci/host/pcie-iproc.c
>>> @@ -952,6 +952,9 @@ static int pci_dma_range_parser_init(struct of_pci_range_parser *parser,
>>> const int na = 3, ns = 2;
>>> int rlen;
>>>
>>> + if (!node)
>>> + return -ENOENT;
>>> +
>>> parser->node = node;
>>> parser->pna = of_n_addr_cells(node);
>>> parser->np = parser->pna + na + ns;
>>>
>>
>>
--
Florian
^ permalink raw reply
* [PATCH v20 0/4] Mediatek MT8173 CMDQ support
From: Horng-Shyang Liao @ 2017-01-13 1:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483499169-16329-1-git-send-email-hs.liao@mediatek.com>
On Wed, 2017-01-04 at 11:06 +0800, HS Liao wrote:
> Hi,
>
> This is Mediatek MT8173 Command Queue(CMDQ) driver. The CMDQ is used
> to help write registers with critical time limitation, such as
> updating display configuration during the vblank. It controls Global
> Command Engine (GCE) hardware to achieve this requirement.
>
> These patches have a build dependency on top of v4.10-rc2.
>
> Changes since v19:
> - rebase to v4.10-rc2
>
> Best regards,
> HS Liao
>
> HS Liao (4):
> dt-bindings: soc: Add documentation for the MediaTek GCE unit
> mailbox: mediatek: Add Mediatek CMDQ driver
> arm64: dts: mt8173: Add GCE node
> soc: mediatek: Add Mediatek CMDQ helper
>
> .../devicetree/bindings/mailbox/mtk-gce.txt | 43 ++
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 10 +
> drivers/mailbox/Kconfig | 10 +
> drivers/mailbox/Makefile | 2 +
> drivers/mailbox/mtk-cmdq-mailbox.c | 596 +++++++++++++++++++++
> drivers/soc/mediatek/Kconfig | 12 +
> drivers/soc/mediatek/Makefile | 1 +
> drivers/soc/mediatek/mtk-cmdq-helper.c | 310 +++++++++++
> include/linux/mailbox/mtk-cmdq-mailbox.h | 75 +++
> include/linux/soc/mediatek/mtk-cmdq.h | 174 ++++++
> 10 files changed, 1233 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/mtk-gce.txt
> create mode 100644 drivers/mailbox/mtk-cmdq-mailbox.c
> create mode 100644 drivers/soc/mediatek/mtk-cmdq-helper.c
> create mode 100644 include/linux/mailbox/mtk-cmdq-mailbox.h
> create mode 100644 include/linux/soc/mediatek/mtk-cmdq.h
>
Hi Jassi, Matthias,
Sorry to disturb you.
Do you have any further comments on CMDQ v20?
Thanks.
HS
^ permalink raw reply
* [PATCH] coresight: STM: Balance enable/disable
From: Chunyan Zhang @ 2017-01-13 2:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e2710e1c-471d-2645-5ce0-30e222c85b52@arm.com>
On 11 January 2017 at 21:59, Suzuki K Poulose <Suzuki.Poulose@arm.com> wrote:
> On 11/01/17 11:41, Chunyan Zhang wrote:
>>
>> On 11 January 2017 at 01:36, Mathieu Poirier <mathieu.poirier@linaro.org>
>> wrote:
>>>
>>> On Tue, Jan 10, 2017 at 11:21:55AM +0000, Suzuki K Poulose wrote:
>>>>
>>>> The stm is automatically enabled when an application sets the policy
>>>> via ->link() call back by using coresight_enable(), which keeps the
>>>> refcount of the current users of the STM. However, the unlink() callback
>>>> issues stm_disable() directly, which leaves the STM turned off, without
>>>> the coresight layer knowing about it. This prevents any further uses
>>>> of the STM hardware as the coresight layer still thinks the STM is
>>>> turned on and doesn't issue an stm_enable(). Even manually enabling
>>>> the STM via sysfs can't really enable the hw.
>>>>
>>>> e.g,
>>>>
>>>> $ echo 1 > $CS_DEVS/$ETR/enable_sink
>>>> $ mkdir -p $CONFIG_FS/stp-policy/$source.0/stm_test/
>>>> $ echo 32768 65535 > $CONFIG_FS/stp-policy/$source.0/stm_test/channels
>>>> $ echo 64 > $CS_DEVS/$source/traceid
>>>> $ ./stm_app
>>>> Sending 64000 byte blocks of pattern 0 at 0us intervals
>>>> Success to map channel(32768~32783) to 0xffffa95fa000
>>>> Sending on channel 32768
>>>> $ dd if=/dev/$ETR of=~/trace.bin.1
>>>> 597+1 records in
>>>> 597+1 records out
>>>> 305920 bytes (306 kB) copied, 0.399952 s, 765 kB/s
>>>> $ ./stm_app
>>>> Sending 64000 byte blocks of pattern 0 at 0us intervals
>>>> Success to map channel(32768~32783) to 0xffff7e9e2000
>>>> Sending on channel 32768
>>>> $ dd if=/dev/$ETR of=~/trace.bin.2
>>>> 0+0 records in
>>>> 0+0 records out
>>>> 0 bytes (0 B) copied, 0.0232083 s, 0.0 kB/s
>>>>
>>>> Note that we don't get any data from the ETR for the second session.
>>>>
>>>> Also dmesg shows :
>>>>
>>>> [ 77.520458] coresight-tmc 20800000.etr: TMC-ETR enabled
>>>> [ 77.537097] coresight-replicator etr_replicator at 20890000: REPLICATOR
>>>> enabled
>>>> [ 77.558828] coresight-replicator main_replicator at 208a0000: REPLICATOR
>>>> enabled
>>>> [ 77.581068] coresight-funnel 208c0000.main_funnel: FUNNEL inport 0
>>>> enabled
>>>> [ 77.602217] coresight-tmc 20840000.etf: TMC-ETF enabled
>>>> [ 77.618422] coresight-stm 20860000.stm: STM tracing enabled
>>>> [ 139.554252] coresight-stm 20860000.stm: STM tracing disabled
>>>> # End of first tracing session
>>>> [ 146.351135] coresight-tmc 20800000.etr: TMC read start
>>>> [ 146.514486] coresight-tmc 20800000.etr: TMC read end
>>>> # Note that the STM is not turned on via
>>>> stm_generic_link()->coresight_enable()
>>>> # and hence none of the components are turned on.
>>>> [ 152.479080] coresight-tmc 20800000.etr: TMC read start
>>>> [ 152.542632] coresight-tmc 20800000.etr: TMC read end
>>>>
>>>> This patch balances the unlink operation by using the
>>>> coresight_disable(),
>>>> keeping the coresight layer in sync with the hardware state.
>>>>
>>>> Fixes: commit 237483aa5cf43 ("coresight: stm: adding driver for
>>>> CoreSight STM component")
>>>> Cc: Pratik Patel <pratikp@codeaurora.org>
>>>> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>> Cc: Chunyan Zhang <zhang.chunyan@linaro.org>
>>>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>>> Cc: stable at vger.kernel.org # 4.7+
>>>> Reported-by: Robert Walker <robert.walker@arm.com>
>>>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>>>> ---
>>>> drivers/hwtracing/coresight/coresight-stm.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/hwtracing/coresight/coresight-stm.c
>>>> b/drivers/hwtracing/coresight/coresight-stm.c
>>>> index 3524452..57b7330 100644
>>>> --- a/drivers/hwtracing/coresight/coresight-stm.c
>>>> +++ b/drivers/hwtracing/coresight/coresight-stm.c
>>>> @@ -356,7 +356,7 @@ static void stm_generic_unlink(struct stm_data
>>>> *stm_data,
>>>> if (!drvdata || !drvdata->csdev)
>>>> return;
>>>>
>>>> - stm_disable(drvdata->csdev, NULL);
>>>> + coresight_disable(drvdata->csdev);
>>>
>>>
>>> This looks valid to me.
>>>
>>> Chunyan, any reason to use stm_disable() directly rather than calling it
>>> as part
>>> of the device OPS in coresight_disable()?
>>
>>
>> I don't think there's some special reason for this. I simply hadn't
>> noticed that these two operations didn't use two balanced functions.
>
>
> Please can I have an Ack/Reviewed -by on it, so that we can push it
> as a fix.
Sure, I've had a run with this patch, it works well, so,
Reviewed-by: Chunyan Zhang <zhang.chunyan@linaro.org>
Thanks,
Chunyan
>
>
> Suzuki
>
^ permalink raw reply
* [PATCH] arm64: dts: mt8173: Fix cpu_thermal cooling-maps contributions
From: Daniel Kurtz @ 2017-01-13 2:30 UTC (permalink / raw)
To: linux-arm-kernel
According to [0], the contribution field for each cooling-device express
their relative power efficiency. Higher weights express higher power
efficiency. Weighting is relative such that if each cooling device has a
weight of 1 they are considered equal. This is particularly useful in
heterogeneous systems where two cooling devices may perform the same kind
of compute, but with different efficiency.
[0] Documentation/thermal/power_allocator.txt
According to Mediatek IC designer, the power efficiency ratio between the
LITTLE core cluster (cooling-device cpu0) and big core cluster
(cooling-device cpu1) is around 3:1 (3072:1024).
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 12e702771f5c..9a3b0d20f7a8 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -182,12 +182,12 @@
map at 0 {
trip = <&target>;
cooling-device = <&cpu0 0 0>;
- contribution = <1024>;
+ contribution = <3072>;
};
map at 1 {
trip = <&target>;
cooling-device = <&cpu2 0 0>;
- contribution = <2048>;
+ contribution = <1024>;
};
};
};
--
2.11.0.390.gc69c2f50cf-goog
^ permalink raw reply related
* [PATCH net-next v2 00/10] net: dsa: Support for pdata in dsa2
From: Vivien Didelot @ 2017-01-13 2:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112034121.27697-1-f.fainelli@gmail.com>
Hi Florian,
Florian Fainelli <f.fainelli@gmail.com> writes:
> Hi all,
>
> This is not exactly new, and was sent before, although back then, I did not
> have an user of the pre-declared MDIO board information, but now we do. Note
> that I have additional changes queued up to have b53 register platform data for
> MIPS bcm47xx and bcm63xx.
>
> Yes I know that we should have the Orion platforms eventually be converted to
> Device Tree, but until that happens, I don't want any remaining users of the
> old "dsa" platform device (hence the previous DTS submissions for ARM/mvebu)
> and, there will be platforms out there that most likely won't never see DT
> coming their way (BCM47xx is almost 100% sure, BCM63xx maybe not in a distant
> future).
>
> We would probably want the whole series to be merged via David Miller's tree
> to simplify things.
>
> Greg, can you Ack/Nack patch 5 since it touched the core LDD?
>
> Thanks!
I've tested this patchset on my mv88e6xxx (DTS) boards to make sure
nothing was broken, since it touches the driver. Looks good!
Tested-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Thanks,
Vivien
^ permalink raw reply
* [PATCH] arm64: hugetlb: fix the wrong return value for huge_ptep_set_access_flags
From: Huang Shijie @ 2017-01-13 2:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111101924.GA18044@e104818-lin.cambridge.arm.com>
On Wed, Jan 11, 2017 at 10:19:25AM +0000, Catalin Marinas wrote:
> The disclaimer is not the main issue. The patch that ended up on the
> list seems to have been corrupted probably by the SMTP server (all tabs
> converted to spaces).
Thanks for pointing this. I will change another SMTP server if the issue
still exists in future.
Thanks
Huang Shijie
^ permalink raw reply
* [PATCH v2 04/12] driver: clk: imx: Add clock driver for imx6sll
From: Jacky Bai @ 2017-01-13 3:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112220536.GP17126@codeaurora.org>
> Subject: Re: [PATCH v2 04/12] driver: clk: imx: Add clock driver for imx6sll
>
> > > > +
> > > > +static const char *pll_bypass_src_sels[] = { "osc", "dummy", };
> > >
> > > All these should be const char * const unless something is wrong.
> >
> > If changed to 'const char * const', it vill has argument type mismatch
> > error, as imx_clk_* wrapper function has argument type 'const char *'.
>
> Hmm that's unfortunate.
>
> >
> > >
> > > > +
> > > > + for (i = 0; i < ARRAY_SIZE(clks_init_on); i++)
> > > > + clk_prepare_enable(clks[clks_init_on[i]]);
> > >
> > > Critical clocks?
> >
> > Yes, these clocks must be always on.
> >
> > >
> > > > +
> > > > + if (IS_ENABLED(CONFIG_USB_MXS_PHY)) {
> > > > + clk_prepare_enable(clks[IMX6SLL_CLK_USBPHY1_GATE]);
> > > > + clk_prepare_enable(clks[IMX6SLL_CLK_USBPHY2_GATE]);
> > >
> > > The phy driver can't enable these?
> >
> > The reason why we enable these two clks here is in below commit commit
> > a5120e89e7e187a91852896f586876c7a2030804
> > Author: Peter Chen <peter.chen@freescale.com>
> > Date: Fri Jan 18 10:38:05 2013 +0800
> > ARM i.MX6: change mxs usbphy clock usage
> >
>
> So can we mark these clks with CLK_IS_CRITICAL flag then instead?
> Or are they disabled out of the bootloader?
>
Sure, using 'CLK_IS_CRITICAL' should be ok for clks_init_on clocks. But for USBPHY*_GATE, it is
only enabled when CONIG_USB_MXC_PHY is true. And another concern is if we need to add CLK_IS_CRITICAL
flag to clks_init_on clocks, we may need to add new wrapper function to register these critical clock. It is not very good.
> >
> > > > + }
> > > > +
> > > > + /* Lower the AHB clock rate before changing the clock source. */
> > > > + clk_set_rate(clks[IMX6SLL_CLK_AHB], 99000000);
> > > > +
> > > > + /* Change periph_pre clock to pll2_bus to adjust AXI rate to 264MHz */
> > > > + clk_set_parent(clks[IMX6SLL_CLK_PERIPH_CLK2_SEL],
> > > clks[IMX6SLL_CLK_PLL3_USB_OTG]);
> > > > + clk_set_parent(clks[IMX6SLL_CLK_PERIPH],
> > > clks[IMX6SLL_CLK_PERIPH_CLK2]);
> > > > + clk_set_parent(clks[IMX6SLL_CLK_PERIPH_PRE],
> > > clks[IMX6SLL_CLK_PLL2_BUS]);
> > > > + clk_set_parent(clks[IMX6SLL_CLK_PERIPH],
> > > > +clks[IMX6SLL_CLK_PERIPH_PRE]);
> > > > +
> > > > + clk_set_rate(clks[IMX6SLL_CLK_AHB], 132000000);
> > >
> > > assigned-clocks for rates now? Or perhaps we shouldn't be exposing
> > > these as clks if they have some sort of complicated rate sequence
> > > switch that we can't guarantee with the clk_ops we have today.
> >
> > These clks will be used by some peripherals, so we need to expose these
> clocks.
> > And the above parent and rate swith sequence is not very easy to be
> > handled in assigned-clocks, So we leave it in this place.
> >
>
> How do we guarantee that the rate switch doesn't happen later on, requiring
> this coordinated sequence of clk operations?
>
This clock sequence is used for increasing the AXI and AHB bus clock rate. In normal
use, it is very rarely that we need to change them again. If we really need to change
AXI and AHB bus clock later, a similar sequence must be used to do this.
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project
^ permalink raw reply
* [PATCH v6 23/25] usb: chipidea: Pullup D+ in device mode via phy APIs
From: Peter Chen @ 2017-01-13 3:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <148426139182.20672.2422337338087784924@sboyd-linaro>
On Thu, Jan 12, 2017 at 02:49:51PM -0800, Stephen Boyd wrote:
> Quoting Peter Chen (2017-01-12 01:50:40)
> > On Wed, Jan 11, 2017 at 04:19:53PM -0800, Stephen Boyd wrote:
> > > Quoting Peter Chen (2017-01-02 22:53:19)
> > > > On Wed, Dec 28, 2016 at 02:57:09PM -0800, Stephen Boyd wrote:
> > > > > If the phy supports it, call phy_set_mode() to pull up D+ when
> > > > > required by setting the mode to PHY_MODE_USB_DEVICE. If we want
> > > > > to remove the pullup, set the mode to PHY_MODE_USB_HOST.
> > > > >
> > > [..]
> > > > > diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> > > > > index 0d532a724d48..6d61fa0689b0 100644
> > > > > --- a/drivers/usb/chipidea/udc.c
> > > > > +++ b/drivers/usb/chipidea/udc.c
> > > > > @@ -1609,10 +1610,15 @@ static int ci_udc_pullup(struct usb_gadget *_gadget, int is_on)
> > > > > return 0;
> > > > >
> > > > > pm_runtime_get_sync(&ci->gadget.dev);
> > > > > - if (is_on)
> > > > > + if (is_on) {
> > > > > + if (ci->phy)
> > > > > + phy_set_mode(ci->phy, PHY_MODE_USB_DEVICE);
> > > > > hw_write(ci, OP_USBCMD, USBCMD_RS, USBCMD_RS);
> > > > > - else
> > > > > + } else {
> > > > > hw_write(ci, OP_USBCMD, USBCMD_RS, 0);
> > > > > + if (ci->phy)
> > > > > + phy_set_mode(ci->phy, PHY_MODE_USB_HOST);
> > > > > + }
> > > > > pm_runtime_put_sync(&ci->gadget.dev);
> > > > >
> > > > > return 0;
> > > >
> > > > Would you describe the use case for it? Why not adding it at
> > > > role switch routine?
> > > >
> > >
> > > This is about pulling up D+. The phy I have requires that we manually
> > > pull up D+ by writing a ULPI register before we set the run/stop bit.
> >
> > Afaik, only controller can pull up dp when it is at device mode by
> > setting USBCMD_RS. At host mode, clear USBCMD_RS will only stopping
> > sending SoF from controller side.
> >
> > I am puzzled why you can pull up D+ by writing an ULPI register, perhaps,
> > your phy needs DP to change before switching the mode? Would you
> > double confirm that?
>
> With the boards I have, vbus is not routed to the phy. Instead, there's
> a vbus comparator on the PMIC where the vbus line from the usb
> receptacle is sent. The vbus extcon driver probes the comparator on the
> PMIC to see if vbus is present or not and then notifies extcon users
> when vbus changes.
>
> The ULPI register we write in the phy is a vendor specific register
> (called MISC_A) that has two bits. If you look at
> qcom_usb_hs_phy_set_mode() in this series you'll see that we set
> VBUSVLDEXTSEL and VBUSVLDEXT. VBUSVLDEXTSEL controls a mux in the phy
> that chooses between an internal comparator, in the case where vbus goes
> to the phy, or an external signal input to the phy, VBUSVLDEXT, to
> consider as the "session valid" signal. It looks like the session valid
> signal drives the D+ pullup resistor in the phy. These bits in MISC_A
> don't matter when the phy is in host mode.
>
> So when the board doesn't route vbus to the phy, we have to toggle the
> VBUSVLDEXT bit to signal to the phy that the vbus is there or not. I
> also see that we're not supposed to toggle the VBUSVLDEXTSEL bit when in
> "normal" operating mode. So perhaps we should do everything in the
> qcom_usb_hs_phy_set_mode() routine during the role switch as you
> suggest, except toggle the VBUSVLDEXT bit. Toggling the VBUSVLDEXT bit
> can be done via some new phy op when the extcon triggers?
Why not call phy_set_mode(phy, DEVICE) directly at ci_handle_vbus_change when
you get extcon vbus event?
--
Best Regards,
Peter Chen
^ permalink raw reply
* [PATCH net-next v2 05/10] drivers: base: Add device_find_class()
From: David Miller @ 2017-01-13 4:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <81f5965c-3484-92d9-5c04-94c5b73735d0@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Thu, 12 Jan 2017 14:50:39 -0800
> Well, this is really so that we don't need to cast the arguments passed
> to device_find_child(), which takes a void *data as well.
Aha, I didn't catch that, my bad.
^ permalink raw reply
* [PATCH v5 1/3] dmaengine: xilinx_dma: Check for channel idle state before submitting dma descriptor
From: Appana Durga Kedareswara Rao @ 2017-01-13 4:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170110062349.GY3573@localhost>
Hi Vinod,
Thanks for the review...
>
> On Sat, Jan 07, 2017 at 12:15:28PM +0530, Kedareswara rao Appana wrote:
> > Add channel idle state to ensure that dma descriptor is not
> > submitted when VDMA engine is in progress.
>
> any reason why you want to make your own varible and not use the HW to
> query
> as done earlier. It is not clear to me why that is removed from description
We need to poll for a bit in the status register to know the dma state.
We are currently doing that in the driver hot path
To avoid this using own variables.
Regards,
Kedar.
^ permalink raw reply
* [PATCH 2/5] clk: sunxi-ng: add support for V3s CCU
From: Icenowy Zheng @ 2017-01-13 4:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112174122.iqzrcyytfefqspwq@lukather>
13.01.2017, 01:41, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> On Fri, Jan 13, 2017 at 01:31:41AM +0800, Icenowy Zheng wrote:
>> ?2017?1?13? 01:19? Maxime Ripard <maxime.ripard@free-electrons.com>???
>> ?>
>> ?> On Thu, Jan 12, 2017 at 03:44:53AM +0800, Icenowy Zheng wrote:
>> ?> >
>> ?> >
>> ?> > 12.01.2017, 03:40, "Icenowy Zheng" <icenowy@aosc.xyz>:
>> ?> > > 11.01.2017, 02:10, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
>> ?> > >> ?On Tue, Jan 03, 2017 at 11:16:26PM +0800, Icenowy Zheng wrote:
>> ?> > >>> ??V3s has a similar but cut-down CCU to H3.
>> ?> > >>>
>> ?> > >>> ??Add support for it.
>> ?> > >>>
>> ?> > >>> ??Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>> ?> > >>
>> ?> > >> ?It looks like there's nothing different but the clocks that you
>> ?> > >> ?register with the H3, please just use the H3 driver.
>> ?> > >
>> ?> > > Nope.
>> ?> > >
>> ?> > > It has a different PLL (PLL_ISP) at different address, and some
>> ?> > > different muxes.
>> ?> >
>> ?> > Forgot to mention the missing of PLL_DE and related misses.
>> ?>
>> ?> Those are not conflicting, it's just a slightly different set of
>> ?> clocks.
>>
>> ?If saying so, we can have only one ccu driver, and make every ccu
>> ?register different set ;-)
>>
>> ?V3s itself is a totally different SoC with H3.
>>
>> ?The relationship of V3s and H3 can be farther than the relationship
>> ?of A33 and H3?
>
> A33 and H3 are an entirely different story. The H3 and A33 have
> conflicting clocks (ie same clocks with different parameters). This is
> not your case.
I think V3s and H3 has also conflicting clocks, e.g. CLK_DE.
The mux of CLK_DE in V3s is PLL_PERIPHx2 and PLL_VIDEO, but on H3
it's PLL_PERIPHx2 and PLL_DE (V3s lacks PLL_DE).
(What I say that there's a PLL missing means that there will also be mux
changes... I think you can understand this... sorry.)
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply
* [PATCH] PCI: iproc: fix kernel crash if dev->of_node not defined
From: Abylay Ospan @ 2017-01-13 4:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6cfba8af-1e9b-cb43-4898-61d6fb8f12ca@broadcom.com>
Hi Florian,
> Still, upstream Linux support for Northstar is Device Tree, and BCMA bus
> should fill in of_nodes accordingly, if not, that's a bug that must be
> fixed at the BCMA layer.
yes, this is a source of the problem. Devices allocated in
'bcma_bus_scan' but of_node doesn't assigned.
Is some code missing in drivers/bcma/ which should assign of_node ?
I can suggest following "hacky" patch for this (works for me):
Author: Abylay Ospan <aospan@netup.ru>
Date: Fri Jan 13 07:24:13 2017 +0300
bcma: force assign 'of_node' for devices on the bus
prevent other code to fail if no 'of_node' defined
Signed-off-by: Abylay Ospan <aospan@netup.ru>
diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
index 2c1798e..4fe1c92 100644
--- a/drivers/bcma/main.c
+++ b/drivers/bcma/main.c
@@ -301,6 +301,11 @@ void bcma_init_bus(struct bcma_bus *bus)
static void bcma_register_core(struct bcma_bus *bus, struct bcma_device *core)
{
int err;
+ struct device * dev;
+
+ dev = bcma_bus_get_host_dev(bus);
+ if (dev && !core->dev.of_node)
+ core->dev.of_node = dev->of_node;
if it's ok I will send this patch in separate email.
>
>>
>>>
>>>>
>>>> Signed-off-by: Abylay Ospan <aospan@netup.ru>
>>>> ---
>>>> drivers/pci/host/pcie-iproc.c | 3 +++
>>>> 1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
>>>> index 3ebc025..f2836a9 100644
>>>> --- a/drivers/pci/host/pcie-iproc.c
>>>> +++ b/drivers/pci/host/pcie-iproc.c
>>>> @@ -952,6 +952,9 @@ static int pci_dma_range_parser_init(struct of_pci_range_parser *parser,
>>>> const int na = 3, ns = 2;
>>>> int rlen;
>>>>
>>>> + if (!node)
>>>> + return -ENOENT;
>>>> +
>>>> parser->node = node;
>>>> parser->pna = of_n_addr_cells(node);
>>>> parser->np = parser->pna + na + ns;
>>>>
>>>
>>>
>
>
> --
> Florian
--
Abylay Ospan,
NetUP Inc.
http://www.netup.tv
^ permalink raw reply related
* [PATCH 56/62] watchdog: tangox_wdt: Convert to use device managed functions
From: Guenter Roeck @ 2017-01-13 5:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111143917.hedhyfu6m5dopag7@pengutronix.de>
On 01/11/2017 06:39 AM, Uwe Kleine-K?nig wrote:
> On Wed, Jan 11, 2017 at 01:31:47PM +0100, Marc Gonzalez wrote:
>> On 11/01/2017 11:52, Guenter Roeck wrote:
>>
>>> On 01/11/2017 01:07 AM, Marc Gonzalez wrote:
>>>
>>>>> @@ -134,12 +134,15 @@ static int tangox_wdt_probe(struct platform_device *pdev)
>>>>> err = clk_prepare_enable(dev->clk);
>>>>> if (err)
>>>>> return err;
>>>>> + err = devm_add_action_or_reset(&pdev->dev,
>>>>> + (void(*)(void *))clk_disable_unprepare,
>>>>> + dev->clk);
>>>>> + if (err)
>>>>> + return err;
>
> This looks wrong. There is no clk_unprepare_disable when
> devm_add_action_or_reset fails.
>
>>>>
>>>> Hello Guenter,
>>>>
>>>> I would rather avoid the function pointer cast.
>>>> How about defining an auxiliary function for the cleanup action?
>>>>
>>>> clk_disable_unprepare() is static inline, so gcc will have to
>>>> define an auxiliary function either way. What do you think?
>>>
>>> Not really. It would just make it more complicated to replace the
>>> call with devm_clk_prepare_enable(), should it ever find its way
>>> into the light of day.
>>
>> More complicated, because the cleanup function will have to be deleted later?
>> The compiler will warn if someone forgets to do that.
>>
>> In my opinion, it's not a good idea to rely on the fact that casting
>> void(*)(struct clk *clk) to void(*)(void *) is likely to work as expected
>> on most platforms. (It has undefined behavior, strictly speaking.)
>
> I would expect it to work on all (Linux) platforms. Anyhow, I wonder if
> there couldn't be found a better solution.
>
> If in the end it looks like the following that would be good I think:
>
> clk = devm_clk_get(...);
> if (IS_ERR(clk))
> ...
>
> ret = devm_clk_prepare_enable(clk)
> if (ret)
> return ret;
>
It turns out that at least one static analyzer complains about different
parameter pointer types in situations like this, and at least one embedded
compiler manages to create function names with embedded parameter type
(eg it appends an 'i' to the function name for each integer parameter).
With that, I consider the typecast to be too risky after all. It may work
for all of today's Linux architectures and compilers, but who knows if I
get flooded with static analyzer warnings, and who knows if gcc version
18.0 or binutils 35.0 makes it truly incompatible (following the logic of
"we can, therefore we do"). Since I also dislike the stub function solution,
at least in this situation, I'll drop all patches touching clk_prepare_enable(),
and wait for devm_clk_prepare_enable() to be available.
Guenter
^ permalink raw reply
* [PATCH v5 1/3] dmaengine: xilinx_dma: Check for channel idle state before submitting dma descriptor
From: Vinod Koul @ 2017-01-13 5:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C246CAC1457055469EF09E3A7AC4E11A4A666658@XAP-PVEXMBX01.xlnx.xilinx.com>
On Fri, Jan 13, 2017 at 04:28:11AM +0000, Appana Durga Kedareswara Rao wrote:
> Hi Vinod,
>
> Thanks for the review...
> >
> > On Sat, Jan 07, 2017 at 12:15:28PM +0530, Kedareswara rao Appana wrote:
> > > Add channel idle state to ensure that dma descriptor is not
> > > submitted when VDMA engine is in progress.
> >
> > any reason why you want to make your own varible and not use the HW to
> > query
> > as done earlier. It is not clear to me why that is removed from description
>
> We need to poll for a bit in the status register to know the dma state.
> We are currently doing that in the driver hot path
> To avoid this using own variables.
It would be worthwhile to document these, down the line people may not
remeber the motivation
--
~Vinod
^ permalink raw reply
* [PATCH] PCI: iproc: fix resource allocation for BCMA PCIe
From: Abylay Ospan @ 2017-01-13 5:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <988ae7dc-ff41-0a06-903f-8681b8ddf13f@broadcom.com>
Hi Ray,
i'm not sure but looks so. Following drivers is doing same allocation on stack:
drivers/pci/host/pcie-designware.c
drivers/pci/host/pcie-rockchip.c
drivers/pci/host/pcie-xilinx.c
drivers/pci/host/pcie-xilinx-nwl.c
drivers/pci/host/pci-host-common.c
-> drivers/pci/host/pci-thunder-ecam.c
-> drivers/pci/host/pci-thunder-pem.c
-> drivers/pci/host/pci-host-generic.c
drivers/pci/host/pci-versatile.c
drivers/pci/host/pci-xgene.c
other drivers is ok. But need to double-check.
Below is more detailed description of the problem.
Problem is visible when second PCIe bridge registering (but can cause
kernel crash with only one PCIe bridge because broken pointer
introduced to 'iomem_resource' anyway). Here is my global
'iomem_resource' list dump:
after first PCIe bridge registered:
[ 3.578650] iomem_resource child=cb039d40 name=PCIe MEM space start=08000000
[ 3.585811] iomem_resource child=cb41da80 name=serial start=18000300
[ 3.592267] iomem_resource child=cb15ce80 name=serial start=18000400
[ 3.598719] iomem_resource child=cb57df00 name=nand start=18028000
[ 3.605001] iomem_resource child=cb57dc80 name=iproc-ext start=18028f00
[ 3.611723] iomem_resource child=cb57da00 name=iproc-idm start=1811a408
[ 3.618433] iomem_resource child=cbfffe80 name=System RAM start=80000000
this dump looks good but before registering second PCIe same dump looks broken:
[ 3.669225] iomem_resource child=cb039d40 name=PCIe MEM space start=40000000
[ 3.676395] iomem_resource child=cb5e3410 name=bcma0:8 start=cb0f6e10
[ 3.682948] iomem_resource child=cb061080 name= start=c1604b04
and second PCIe registration fail with:
[ 3.694207] pcie_iproc_bcma bcma0:8: resource collision: [mem
0x40000000-0x47ffffff] conflicts with PCIe MEM space [mem
0x40000000-0x47ffffff]
[ 3.707024] pcie_iproc_bcma bcma0:8: PCIe controller setup failed
address 0xcb039d40 from this dumps is allocated on stack and is not
valid after 'iproc_pcie_bcma_probe' exit.
Proposed patch is fixing this issue.
2017-01-12 19:40 GMT-05:00 Ray Jui <ray.jui@broadcom.com>:
> Hi Abylay,
>
> On 1/12/2017 3:58 PM, Abylay Ospan wrote:
>> Resource allocated on stack was saved by 'devm_request_resource' to
>> global 'iomem_resource' but become invalid after 'iproc_pcie_bcma_probe' exit.
>> So the global 'iomem_resource' was poisoned. This may cause kernel crash
>> or second PCIe bridge registration failure.
>>
>> Tested on Broadcom NorthStar machine ('Edgecore ECW7220-L') with two PCIe wifi
>> adapters (b43 BCM4331 and ath10k QCA988X).
>>
>> Signed-off-by: Abylay Ospan <aospan@netup.ru>
>
> I have not yet looked into this in great details. But if what you
> claimed is true, do we have the same problem with multiple PCIe host
> drivers that all have their resource allocated on the stack and have
> 'devm_request_resource' called to save it?
>
> Thanks,
>
> Ray
>
>> ---
>> drivers/pci/host/pcie-iproc-bcma.c | 18 ++++++++----------
>> drivers/pci/host/pcie-iproc.h | 2 ++
>> 2 files changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/pci/host/pcie-iproc-bcma.c b/drivers/pci/host/pcie-iproc-bcma.c
>> index bd4c9ec..28f9b89 100644
>> --- a/drivers/pci/host/pcie-iproc-bcma.c
>> +++ b/drivers/pci/host/pcie-iproc-bcma.c
>> @@ -44,8 +44,6 @@ static int iproc_pcie_bcma_probe(struct bcma_device *bdev)
>> {
>> struct device *dev = &bdev->dev;
>> struct iproc_pcie *pcie;
>> - LIST_HEAD(res);
>> - struct resource res_mem;
>> int ret;
>>
>> pcie = devm_kzalloc(dev, sizeof(*pcie), GFP_KERNEL);
>> @@ -62,21 +60,21 @@ static int iproc_pcie_bcma_probe(struct bcma_device *bdev)
>> }
>>
>> pcie->base_addr = bdev->addr;
>> + INIT_LIST_HEAD(&pcie->resources);
>>
>> - res_mem.start = bdev->addr_s[0];
>> - res_mem.end = bdev->addr_s[0] + SZ_128M - 1;
>> - res_mem.name = "PCIe MEM space";
>> - res_mem.flags = IORESOURCE_MEM;
>> - pci_add_resource(&res, &res_mem);
>> + pcie->res_mem.start = bdev->addr_s[0];
>> + pcie->res_mem.end = bdev->addr_s[0] + SZ_128M - 1;
>> + pcie->res_mem.name = "PCIe MEM space";
>> + pcie->res_mem.flags = IORESOURCE_MEM;
>> + pcie->res_mem.child = NULL;
>> + pci_add_resource(&pcie->resources, &pcie->res_mem);
>>
>> pcie->map_irq = iproc_pcie_bcma_map_irq;
>>
>> - ret = iproc_pcie_setup(pcie, &res);
>> + ret = iproc_pcie_setup(pcie, &pcie->resources);
>> if (ret)
>> dev_err(dev, "PCIe controller setup failed\n");
>>
>> - pci_free_resource_list(&res);
>> -
>> bcma_set_drvdata(bdev, pcie);
>> return ret;
>> }
>> diff --git a/drivers/pci/host/pcie-iproc.h b/drivers/pci/host/pcie-iproc.h
>> index 04fed8e..866d649 100644
>> --- a/drivers/pci/host/pcie-iproc.h
>> +++ b/drivers/pci/host/pcie-iproc.h
>> @@ -105,6 +105,8 @@ struct iproc_pcie {
>>
>> bool need_msi_steer;
>> struct iproc_msi *msi;
>> + struct resource res_mem;
>> + struct list_head resources;
>> };
>>
>> int iproc_pcie_setup(struct iproc_pcie *pcie, struct list_head *res);
>>
--
Abylay Ospan,
NetUP Inc.
http://www.netup.tv
^ permalink raw reply
* [PATCH v5 1/3] dmaengine: xilinx_dma: Check for channel idle state before submitting dma descriptor
From: Appana Durga Kedareswara Rao @ 2017-01-13 5:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113052939.GP3573@localhost>
Hi Vinod,
Thanks for the review...
>
> On Fri, Jan 13, 2017 at 04:28:11AM +0000, Appana Durga Kedareswara Rao
> wrote:
> > Hi Vinod,
> >
> > Thanks for the review...
> > >
> > > On Sat, Jan 07, 2017 at 12:15:28PM +0530, Kedareswara rao Appana wrote:
> > > > Add channel idle state to ensure that dma descriptor is not
> > > > submitted when VDMA engine is in progress.
> > >
> > > any reason why you want to make your own varible and not use the HW
> > > to query as done earlier. It is not clear to me why that is removed
> > > from description
> >
> > We need to poll for a bit in the status register to know the dma state.
> > We are currently doing that in the driver hot path To avoid this using
> > own variables.
>
> It would be worthwhile to document these, down the line people may not
> remeber the motivation
Sure will add comments during the variable initialization
In the driver...
Regards,
Kedar.
>
>
> --
> ~Vinod
^ permalink raw reply
* [PATCH v5 3/3] dmaengine: xilinx_dma: Fix race condition in the driver for multiple descriptor scenario
From: Vinod Koul @ 2017-01-13 5:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C246CAC1457055469EF09E3A7AC4E11A4A6662F1@XAP-PVEXMBX01.xlnx.xilinx.com>
On Thu, Jan 12, 2017 at 02:19:49PM +0000, Appana Durga Kedareswara Rao wrote:
> Hi Vinod,
>
> Thanks for the review...
>
> > On Sat, Jan 07, 2017 at 12:15:30PM +0530, Kedareswara rao Appana wrote:
> > > When driver is handling AXI DMA SoftIP When user submits multiple
> > > descriptors back to back on the S2MM(recv) side with the current
> > > driver flow the last buffer descriptor next bd points to a invalid
> > > location resulting the invalid data or errors in the DMA engine.
> >
> > Can you rephrase this, it a bit hard to understand.
>
> When DMA is receiving packets h/w expects the descriptors
> Should be in the form of a ring (I mean h/w buffer descriptor
> Next descriptor field should always point to valid address
> So that when DMA engine go and fetch that next descriptor it always
> Sees a valid address).
>
>
> But with the current driver implementation when user queues
> Multiple descriptors the last descriptor next descriptor field
> Pointing to an invalid location causing data corruption or
> Errors from the DMA h/w engine...
>
> To avoid this issue creating a Buffer descriptor Chain during
> Channel allocation and using those buffer descriptors for processing
> User requested data.
Is it not doable to to modify the next pointer to point to subsequent
transaction. IOW you are modifying tail descriptor to point to subsequent
descriptor.
Btw how and when does DMA stop, assuming it is circular it never would,
isn't there a valid/stop flag associated with a descriptor which tells DMA
engine what to do next
Btw there is something wrong with your MUA perhaps line are titlecased for
no reason. This is typically behavious of non linux tool which may not be
great tool for this work.
>
> Please let me know if the above explanation is not clear will explain in detail....
>
> >
> > >
> > > This patch fixes this issue by creating a BD Chain during
> >
> > whats a BD?
>
> Buffer descriptor.
Thats nowhere mentioned..
>
> >
> > > channel allocation itself and use those BD's.
> > >
> > > Signed-off-by: Kedareswara rao Appana <appanad@xilinx.com>
> > > ---
> > >
> > > drivers/dma/xilinx/xilinx_dma.c | 133
> > > +++++++++++++++++++++++++---------------
> > > 1 file changed, 83 insertions(+), 50 deletions(-)
> > >
> > > diff --git a/drivers/dma/xilinx/xilinx_dma.c
> > > b/drivers/dma/xilinx/xilinx_dma.c index 0e9c02e..af2159d 100644
> > > --- a/drivers/dma/xilinx/xilinx_dma.c
> > > +++ b/drivers/dma/xilinx/xilinx_dma.c
> > > @@ -163,6 +163,7 @@
> > > #define XILINX_DMA_BD_SOP BIT(27)
> > > #define XILINX_DMA_BD_EOP BIT(26)
> > > #define XILINX_DMA_COALESCE_MAX 255
> > > +#define XILINX_DMA_NUM_DESCS 255
> >
> > why 255?
>
> It is not an h/w limitation
> Allocating 255 descriptors (Each descriptor is capable of sending 7MB data)
> So roughly using allocated descriptors DMA engine can transfer 1GB data
> And in the driver we are reusing the allocated descriptors when they are free.
>
> Regards,
> Kedar.
--
~Vinod
^ permalink raw reply
* arm64: dts: mt8173: add node for thermal calibration
From: Dawei Chien @ 2017-01-13 5:52 UTC (permalink / raw)
To: linux-arm-kernel
From: "dawei.chien@mediatek.com" <dawei.chien@mediatek.com>
Add this for supporting thermal calibration by e-fuse data.
Signed-off-by: Dawei Chien <dawei.chien@mediatek.com>
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 12e7027..adfac1e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -401,6 +401,11 @@
efuse: efuse at 10206000 {
compatible = "mediatek,mt8173-efuse";
reg = <0 0x10206000 0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ thermal_calibration: calib at 528 {
+ reg = <0x528 0xc>;
+ };
};
apmixedsys: clock-controller at 10209000 {
@@ -574,6 +579,8 @@
resets = <&pericfg MT8173_PERI_THERM_SW_RST>;
mediatek,auxadc = <&auxadc>;
mediatek,apmixedsys = <&apmixedsys>;
+ nvmem-cells = <&thermal_calibration>;
+ nvmem-cell-names = "calibration-data";
};
nor_flash: spi at 1100d000 {
--
1.9.1
^ permalink raw reply related
* [PATCH] PCI: iproc: fix kernel crash if dev->of_node not defined
From: Abylay Ospan @ 2017-01-13 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6891f43f-25e7-1411-800e-97e6788f2f27@gmail.com>
FYI,
here is my tree (based on linux-next):
https://github.com/aospan/linux-next-bcm4708-edgecore-ecw7220-l/commits/master
last patches adding defconfig and dts I'm using for this device. This
files are draft yet.
2017-01-12 19:22 GMT-05:00 Florian Fainelli <f.fainelli@gmail.com>:
> On 01/12/2017 04:20 PM, Abylay Ospan wrote:
>> pcie->dev->of_node not always defined (NULL) and can cause crash:
>>
>> [ 19.053195] Unable to handle kernel NULL pointer dereference at
>> virtual address 00000020
>> [<c0b0370c>] (of_n_addr_cells) from [<c06599c4>]
>> (iproc_pcie_setup+0x30c/0xce0)
>>
>> this patch adds sanity check to prevent crash.
>
> Humm, how can it not be defined based on your earlier comment that you
> are using this on NSP which is Device Tree exclusively? I would agree if
> this was seen on e.g: MIPS/BCMA (47xx).
>
>>
>> Signed-off-by: Abylay Ospan <aospan@netup.ru>
>> ---
>> drivers/pci/host/pcie-iproc.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
>> index 3ebc025..f2836a9 100644
>> --- a/drivers/pci/host/pcie-iproc.c
>> +++ b/drivers/pci/host/pcie-iproc.c
>> @@ -952,6 +952,9 @@ static int pci_dma_range_parser_init(struct of_pci_range_parser *parser,
>> const int na = 3, ns = 2;
>> int rlen;
>>
>> + if (!node)
>> + return -ENOENT;
>> +
>> parser->node = node;
>> parser->pna = of_n_addr_cells(node);
>> parser->np = parser->pna + na + ns;
>>
>
>
> --
> Florian
--
Abylay Ospan,
NetUP Inc.
http://www.netup.tv
^ permalink raw reply
* [PATCH] arm64/mm: use phys_addr_t
From: miles.chen at mediatek.com @ 2017-01-13 5:59 UTC (permalink / raw)
To: linux-arm-kernel
From: Miles Chen <miles.chen@mediatek.com>
Use phys_addr_t instead of unsigned long for the
return value of __pa(), make code easy to understand.
Signed-off-by: Miles Chen <miles.chen@mediatek.com>
---
arch/arm64/mm/mmu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 17243e4..7eb7c21 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -359,8 +359,8 @@ static void create_mapping_late(phys_addr_t phys, unsigned long virt,
static void __init __map_memblock(pgd_t *pgd, phys_addr_t start, phys_addr_t end)
{
- unsigned long kernel_start = __pa(_text);
- unsigned long kernel_end = __pa(__init_begin);
+ phys_addr_t kernel_start = __pa(_text);
+ phys_addr_t kernel_end = __pa(__init_begin);
/*
* Take care not to create a writable alias for the
--
1.9.1
^ permalink raw reply related
* [PATCH v5 3/3] dmaengine: xilinx_dma: Fix race condition in the driver for multiple descriptor scenario
From: Appana Durga Kedareswara Rao @ 2017-01-13 6:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113053627.GQ3573@localhost>
Hi Vinod,
Thanks for the review...
[Snip]
> >
> > > On Sat, Jan 07, 2017 at 12:15:30PM +0530, Kedareswara rao Appana wrote:
> > > > When driver is handling AXI DMA SoftIP When user submits multiple
> > > > descriptors back to back on the S2MM(recv) side with the current
> > > > driver flow the last buffer descriptor next bd points to a invalid
> > > > location resulting the invalid data or errors in the DMA engine.
> > >
> > > Can you rephrase this, it a bit hard to understand.
> >
> > When DMA is receiving packets h/w expects the descriptors Should be in
> > the form of a ring (I mean h/w buffer descriptor Next descriptor field
> > should always point to valid address So that when DMA engine go and
> > fetch that next descriptor it always Sees a valid address).
> >
> >
> > But with the current driver implementation when user queues Multiple
> > descriptors the last descriptor next descriptor field Pointing to an
> > invalid location causing data corruption or Errors from the DMA h/w
> > engine...
> >
> > To avoid this issue creating a Buffer descriptor Chain during Channel
> > allocation and using those buffer descriptors for processing User
> > requested data.
>
> Is it not doable to to modify the next pointer to point to subsequent transaction.
> IOW you are modifying tail descriptor to point to subsequent descriptor.
>
> Btw how and when does DMA stop, assuming it is circular it never would, isn't
> there a valid/stop flag associated with a descriptor which tells DMA engine what
> to do next
There are two registers that controls the DMA transfers.
Current descriptor and tail descriptor register.
When current descriptor reaches tail descriptor dma engine will pause.
When reprogramming the tail descriptor the DMA engine will starts fetching descriptors again.
But with the existing driver flow if we reprogram the tail descriptor
The tail descriptor next descriptor field is pointing to an invalid location
Causing data corruption...
>
>
> Btw there is something wrong with your MUA perhaps line are titlecased for no
> reason. This is typically behavious of non linux tool which may not be great tool
> for this work.
Thanks for pointing it out.
I usually replies from outlook from a windows machine.
Will check with others in my team how they configured their mail client.
>
> >
> > Please let me know if the above explanation is not clear will explain in detail....
> >
> > >
> > > >
> > > > This patch fixes this issue by creating a BD Chain during
> > >
> > > whats a BD?
> >
> > Buffer descriptor.
>
> Thats nowhere mentioned..
Yep sorry I should have been mentioned it...
Regards,
Kedar.
^ permalink raw reply
* [PATCH v5 3/3] dmaengine: xilinx_dma: Fix race condition in the driver for multiple descriptor scenario
From: Vinod Koul @ 2017-01-13 6:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C246CAC1457055469EF09E3A7AC4E11A4A6666CF@XAP-PVEXMBX01.xlnx.xilinx.com>
On Fri, Jan 13, 2017 at 06:00:44AM +0000, Appana Durga Kedareswara Rao wrote:
> Hi Vinod,
>
> Thanks for the review...
>
> [Snip]
> > >
> > > > On Sat, Jan 07, 2017 at 12:15:30PM +0530, Kedareswara rao Appana wrote:
> > > > > When driver is handling AXI DMA SoftIP When user submits multiple
> > > > > descriptors back to back on the S2MM(recv) side with the current
> > > > > driver flow the last buffer descriptor next bd points to a invalid
> > > > > location resulting the invalid data or errors in the DMA engine.
> > > >
> > > > Can you rephrase this, it a bit hard to understand.
> > >
> > > When DMA is receiving packets h/w expects the descriptors Should be in
> > > the form of a ring (I mean h/w buffer descriptor Next descriptor field
> > > should always point to valid address So that when DMA engine go and
> > > fetch that next descriptor it always Sees a valid address).
> > >
> > >
> > > But with the current driver implementation when user queues Multiple
> > > descriptors the last descriptor next descriptor field Pointing to an
> > > invalid location causing data corruption or Errors from the DMA h/w
> > > engine...
> > >
> > > To avoid this issue creating a Buffer descriptor Chain during Channel
> > > allocation and using those buffer descriptors for processing User
> > > requested data.
> >
> > Is it not doable to to modify the next pointer to point to subsequent transaction.
> > IOW you are modifying tail descriptor to point to subsequent descriptor.
> >
> > Btw how and when does DMA stop, assuming it is circular it never would, isn't
> > there a valid/stop flag associated with a descriptor which tells DMA engine what
> > to do next
>
> There are two registers that controls the DMA transfers.
> Current descriptor and tail descriptor register.
> When current descriptor reaches tail descriptor dma engine will pause.
>
> When reprogramming the tail descriptor the DMA engine will starts fetching descriptors again.
>
> But with the existing driver flow if we reprogram the tail descriptor
> The tail descriptor next descriptor field is pointing to an invalid location
> Causing data corruption...
So the solution is..?
> > Btw there is something wrong with your MUA perhaps line are titlecased for no
> > reason. This is typically behavious of non linux tool which may not be great tool
> > for this work.
>
> Thanks for pointing it out.
> I usually replies from outlook from a windows machine.
> Will check with others in my team how they configured their mail client.
Yeah that isnt right tool for the job. See
Documentation/process/email-clients.rst
FWIW, I use mutt, vim as editor with exchange servers, seems to work well
for me now.
--
~Vinod
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox