* Re: [PATCH v15 2/2] i2c: core: support bus regulator controlling in adapter
From: Grygorii Strashko @ 2020-05-22 17:59 UTC (permalink / raw)
To: Bibby Hsieh, Wolfram Sang, Bartosz Golaszewski, linux-i2c
Cc: tfiga, drinkcat, srv_heupstream, robh+dt, mark.rutland,
devicetree, Rafael J . Wysocki
In-Reply-To: <20200519072729.7268-3-bibby.hsieh@mediatek.com>
On 19/05/2020 10:27, Bibby Hsieh wrote:
> Although in the most platforms, the bus power of i2c
> are alway on, some platforms disable the i2c bus power
> in order to meet low power request.
>
> We get and enable bulk regulator in i2c adapter device.
>
> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> ---
> drivers/i2c/i2c-core-base.c | 84 +++++++++++++++++++++++++++++++++++++
> include/linux/i2c.h | 2 +
> 2 files changed, 86 insertions(+)
>
> diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
> index 5cc0b0ec5570..e1cc8d46bc51 100644
> --- a/drivers/i2c/i2c-core-base.c
> +++ b/drivers/i2c/i2c-core-base.c
> @@ -313,12 +313,14 @@ static int i2c_smbus_host_notify_to_irq(const struct i2c_client *client)
> static int i2c_device_probe(struct device *dev)
> {
> struct i2c_client *client = i2c_verify_client(dev);
> + struct i2c_adapter *adap;
> struct i2c_driver *driver;
> int status;
>
> if (!client)
> return 0;
>
> + adap = client->adapter;
> driver = to_i2c_driver(dev->driver);
>
> client->irq = client->init_irq;
> @@ -378,6 +380,12 @@ static int i2c_device_probe(struct device *dev)
>
> dev_dbg(dev, "probe\n");
>
> + status = regulator_enable(adap->bus_regulator);
> + if (status < 0) {
> + dev_err(&adap->dev, "Failed to enable power regulator\n");
> + goto err_clear_wakeup_irq;
> + }
> +
> status = of_clk_set_defaults(dev->of_node, false);
> if (status < 0)
> goto err_clear_wakeup_irq;
> @@ -414,12 +422,14 @@ static int i2c_device_probe(struct device *dev)
> static int i2c_device_remove(struct device *dev)
> {
> struct i2c_client *client = i2c_verify_client(dev);
> + struct i2c_adapter *adap;
> struct i2c_driver *driver;
> int status = 0;
>
> if (!client || !dev->driver)
> return 0;
>
> + adap = client->adapter;
> driver = to_i2c_driver(dev->driver);
> if (driver->remove) {
> dev_dbg(dev, "remove\n");
> @@ -427,6 +437,8 @@ static int i2c_device_remove(struct device *dev)
> }
>
> dev_pm_domain_detach(&client->dev, true);
> + if (!pm_runtime_status_suspended(&client->dev))
> + regulator_disable(adap->bus_regulator);
Not sure this check is correct.
i2c_device_probe()
- regulator_enable - 1
pm_runtime_get()
- regulator_enable - 2
i2c_device_remove()
- pm_runtime_status_suspended() flase
- regulator_disable() - 1 --> still active?
Sorry, I probably missing smth.
>
> dev_pm_clear_wake_irq(&client->dev);
> device_init_wakeup(&client->dev, false);
> @@ -438,6 +450,72 @@ static int i2c_device_remove(struct device *dev)
> return status;
> }
>
[...]
--
Best regards,
grygorii
^ permalink raw reply
* Re: [EXT] Re: [PATCH net 3/4] ARM: dts: imx6: update fec gpr property to match new format
From: Fuzzey, Martin @ 2020-05-22 18:02 UTC (permalink / raw)
To: Andy Duan
Cc: Andrew Lunn, David S. Miller, netdev@vger.kernel.org,
robh+dt@kernel.org, shawnguo@kernel.org,
devicetree@vger.kernel.org
In-Reply-To: <AM6PR0402MB360728F404F966B9EF404697FFB40@AM6PR0402MB3607.eurprd04.prod.outlook.com>
Hi Andy,
On Fri, 22 May 2020, 03:01 Andy Duan, <fugang.duan@nxp.com> wrote:
>
> Andrew, many customers require the wol feature, NXP NPI release always support
> the wol feature to match customers requirement.
>
> And some customers' board only design one ethernet instance based on imx6sx/imx7d/
> Imx8 serial, but which instance we never know, maybe enet1, maybe enet2. So we should
> supply different values for gpr.
>
> So, it is very necessary to support wol feature for multiple instances.
>
Yes, I don't think anyone is saying otherwise.
The problem is just that there are already .dtsi files for i.MX chips
having multiple ethernet interfaces
in the mainline kernel (at least imx6ui.dtsi, imx6sx.dts, imx7d.dtsi)
but that this patch series does not
modify those files to use the new DT format.
It currently only modifies the dts files that are already supported by
hardcoded values in the driver.
As to not knowing which instance it shouldn't matter.
The base dtsi can declare both/all ethernet interfaces with the
appropriate GPR bits.
Both set to status = "disabled".
Then the board specific dts file sets status="okay" and activates wol
by adding "
"fsl,magic-packet" if the hardaware supports it
(because that depends on things beyond the SoC, like how the ethernet
PHY is clocked and powered.)
Martin
^ permalink raw reply
* Re: [PATCH 3/4] remoteproc: add support for a new 64-bit trace version
From: Clément Leger @ 2020-05-22 18:03 UTC (permalink / raw)
To: Bjorn Andersson
Cc: s-anna, Rob Herring, Mathieu Poirier, Loic PALLARDY,
Arnaud Pouliquen, Lokesh Vutla, linux-remoteproc, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20200522173346.GJ11847@yoga>
Hi Suman,
----- On 22 May, 2020, at 19:33, Bjorn Andersson bjorn.andersson@linaro.org wrote:
> On Fri 22 May 09:54 PDT 2020, Suman Anna wrote:
>
>> On 5/21/20 2:42 PM, Suman Anna wrote:
>> > Hi Bjorn,
>> >
>> > On 5/21/20 1:04 PM, Bjorn Andersson wrote:
>> > > On Wed 25 Mar 13:47 PDT 2020, Suman Anna wrote:
> [..]
>> > > > diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> [..]
>> > > > +struct fw_rsc_trace2 {
>> > >
>> > > Sounds more like fw_rsc_trace64 to me - in particular since the version
>> > > of trace2 is 1...
>> >
>> > Yeah, will rename this.
>> >
>> > >
>> > > > + u32 padding;
>> > > > + u64 da;
>> > > > + u32 len;
>> > > > + u32 reserved;
>> > >
>> > > What's the purpose of this reserved field?
>> >
>> > Partly to make sure the entire resource is aligned on an 8-byte, and
>> > partly copied over from fw_rsc_trace entry. I guess 32-bits is already
>> > large enough of a size for trace entries irrespective of 32-bit or
>> > 64-bit traces, so I doubt if we want to make the len field also a u64.
>>
>> Looking at this again, I can drop both padding and reserved fields, if I
>> move the len field before da. Any preferences/comments?
Not only the in structure alignment matters but also in the resource table.
Since the resource table is often packed (see [1] for instance), if a
[1] https://github.com/OpenAMP/open-amp/blob/master/apps/machine/zynqmp_r5/rsc_table.h
>>
>
> Sounds good to me.
>
> Thanks,
> Bjorn
^ permalink raw reply
* Re: [PATCH 3/4] remoteproc: add support for a new 64-bit trace version
From: Clément Leger @ 2020-05-22 18:10 UTC (permalink / raw)
To: Bjorn Andersson
Cc: s-anna, Rob Herring, Mathieu Poirier, Loic PALLARDY,
Arnaud Pouliquen, Lokesh Vutla, linux-remoteproc, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <1739080680.4218297.1590170621467.JavaMail.zimbra@kalray.eu>
----- On 22 May, 2020, at 20:03, Clément Leger cleger@kalray.eu wrote:
> Hi Suman,
>
> ----- On 22 May, 2020, at 19:33, Bjorn Andersson bjorn.andersson@linaro.org
> wrote:
>
>> On Fri 22 May 09:54 PDT 2020, Suman Anna wrote:
>>
>>> On 5/21/20 2:42 PM, Suman Anna wrote:
>>> > Hi Bjorn,
>>> >
>>> > On 5/21/20 1:04 PM, Bjorn Andersson wrote:
>>> > > On Wed 25 Mar 13:47 PDT 2020, Suman Anna wrote:
>> [..]
>>> > > > diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
>> [..]
>>> > > > +struct fw_rsc_trace2 {
>>> > >
>>> > > Sounds more like fw_rsc_trace64 to me - in particular since the version
>>> > > of trace2 is 1...
>>> >
>>> > Yeah, will rename this.
>>> >
>>> > >
>>> > > > + u32 padding;
>>> > > > + u64 da;
>>> > > > + u32 len;
>>> > > > + u32 reserved;
>>> > >
>>> > > What's the purpose of this reserved field?
>>> >
>>> > Partly to make sure the entire resource is aligned on an 8-byte, and
>>> > partly copied over from fw_rsc_trace entry. I guess 32-bits is already
>>> > large enough of a size for trace entries irrespective of 32-bit or
>>> > 64-bit traces, so I doubt if we want to make the len field also a u64.
>>>
>>> Looking at this again, I can drop both padding and reserved fields, if I
>>> move the len field before da. Any preferences/comments?
>
Sorry, my message went a bit too fast... So as I was saying:
Not only the in-structure alignment matters but also in the resource table.
Since the resource table is often packed (see [1] for instance), if a trace
resource is embedded in the resource table after another resource aligned
on 32 bits only, your 64 bits trace field will potentially end up
misaligned.
To overcome this, there is multiple solutions:
- Split the 64 bits fields into 32bits low and high parts:
Since all resources are aligned on 32bits, it will be ok
- Use memcpy_from/to_io when reading/writing such fields
As I said in a previous message this should probably be used since
the memories that are accessed by rproc are io mem (ioremap in almost
all drivers).
Regards,
Clément
[1] https://github.com/OpenAMP/open-amp/blob/master/apps/machine/zynqmp_r5/rsc_table.h
>
>
>
>
>>>
>>
>> Sounds good to me.
>>
>> Thanks,
> > Bjorn
^ permalink raw reply
* Re: [PATCH net-next v2 2/4] net: phy: Add a helper to return the index for of the internal delay
From: Dan Murphy @ 2020-05-22 18:27 UTC (permalink / raw)
To: Florian Fainelli, andrew, hkallweit1, davem, robh
Cc: netdev, linux-kernel, devicetree
In-Reply-To: <da85ecb0-1da1-2ccd-0830-a3ec18ee486c@gmail.com>
Florian
On 5/22/20 11:11 AM, Florian Fainelli wrote:
>
> On 5/22/2020 5:25 AM, Dan Murphy wrote:
>> Add a helper function that will return the index in the array for the
>> passed in internal delay value. The helper requires the array, size and
>> delay value.
>>
>> The helper will then return the index for the exact match or return the
>> index for the index to the closest smaller value.
>>
>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>> ---
>> drivers/net/phy/phy_device.c | 45 ++++++++++++++++++++++++++++++++++++
>> include/linux/phy.h | 2 ++
>> 2 files changed, 47 insertions(+)
>>
>> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
>> index 7481135d27ab..40f53b379d2b 100644
>> --- a/drivers/net/phy/phy_device.c
>> +++ b/drivers/net/phy/phy_device.c
>> @@ -2661,6 +2661,51 @@ void phy_get_pause(struct phy_device *phydev, bool *tx_pause, bool *rx_pause)
>> }
>> EXPORT_SYMBOL(phy_get_pause);
>>
>> +/**
>> + * phy_get_delay_index - returns the index of the internal delay
>> + * @phydev: phy_device struct
>> + * @delay_values: array of delays the PHY supports
>> + * @size: the size of the delay array
>> + * @delay: the delay to be looked up
>> + *
>> + * Returns the index within the array of internal delay passed in.
> Can we consider using s32 for storage that way the various
> of_read_property_read_u32() are a natural fit (int works too, but I
> would prefer being explicit).
Ack
>
>> + */
>> +int phy_get_delay_index(struct phy_device *phydev, int *delay_values, int size,
>> + int delay)
>> +{
>> + int i;
>> +
>> + if (size <= 0)
>> + return -EINVAL;
>> +
>> + if (delay <= delay_values[0])
>> + return 0;
>> +
>> + if (delay > delay_values[size - 1])
>> + return size - 1;
> Does not that assume that the delays are sorted by ascending order, if
> so, can you make it clear in the kernel doc?
Yes I guess it does. I can add this to the k doc
>
>> +
>> + for (i = 0; i < size; i++) {
>> + if (delay == delay_values[i])
>> + return i;
>> +
>> + /* Find an approximate index by looking up the table */
>> + if (delay > delay_values[i - 1] &&
> && i > 0 so you do not accidentally under-run the array?
Yes and no it maybe better to start the for loop with i being
initialized to 1 since the zeroth element is already validated above.
Dan
^ permalink raw reply
* [PATCHv3 0/2] Add support for replicators which loses context on clock removal
From: Sai Prakash Ranjan @ 2020-05-22 18:36 UTC (permalink / raw)
To: Mathieu Poirier, Suzuki K Poulose, Mike Leach, devicetree,
Rob Herring
Cc: linux-arm-kernel, linux-kernel, linux-arm-msm, Stephen Boyd,
Sai Prakash Ranjan
This series is mainly to add support for replicators
which lose context on removing AMBA clock like on SC7180
SoC where replicator in AOSS domain loses context.
v2 - https://lore.kernel.org/patchwork/cover/1244340/
More discussion is found here - https://lore.kernel.org/patchwork/patch/1231182/
Changes since v2:
* Added DT maintainers which I missed in v2
* Added proper kernel-doc and header as per Mathieu
Sai Prakash Ranjan (2):
coresight: replicator: Reset replicator if context is lost
dt-bindings: arm: coresight: Add optional property to replicators
.../devicetree/bindings/arm/coresight.txt | 6 ++
.../coresight/coresight-replicator.c | 55 +++++++++++++------
2 files changed, 44 insertions(+), 17 deletions(-)
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* [PATCHv3 1/2] coresight: replicator: Reset replicator if context is lost
From: Sai Prakash Ranjan @ 2020-05-22 18:36 UTC (permalink / raw)
To: Mathieu Poirier, Suzuki K Poulose, Mike Leach, devicetree,
Rob Herring
Cc: linux-arm-kernel, linux-kernel, linux-arm-msm, Stephen Boyd,
Sai Prakash Ranjan
In-Reply-To: <cover.1590171891.git.saiprakash.ranjan@codeaurora.org>
On some QCOM SoCs, replicators in Always-On domain loses its
context as soon as the clock is disabled. Currently as a part
of pm_runtime workqueue, clock is disabled after the replicator
is initialized by amba_pm_runtime_suspend assuming that context
is not lost which is not true for replicators with such
limitations. So add a new property "qcom,replicator-loses-context"
to identify such replicators and reset them.
Suggested-by: Mike Leach <mike.leach@linaro.org>
Reviewed-by: Mike Leach <mike.leach@linaro.org>
Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
---
.../coresight/coresight-replicator.c | 55 +++++++++++++------
1 file changed, 38 insertions(+), 17 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-replicator.c b/drivers/hwtracing/coresight/coresight-replicator.c
index e7dc1c31d20d..9d3a8f915784 100644
--- a/drivers/hwtracing/coresight/coresight-replicator.c
+++ b/drivers/hwtracing/coresight/coresight-replicator.c
@@ -14,6 +14,7 @@
#include <linux/err.h>
#include <linux/slab.h>
#include <linux/pm_runtime.h>
+#include <linux/property.h>
#include <linux/clk.h>
#include <linux/of.h>
#include <linux/coresight.h>
@@ -32,12 +33,14 @@ DEFINE_CORESIGHT_DEVLIST(replicator_devs, "replicator");
* @atclk: optional clock for the core parts of the replicator.
* @csdev: component vitals needed by the framework
* @spinlock: serialize enable/disable operations.
+ * @check_idfilter_val: check if the context is lost upon clock removal.
*/
struct replicator_drvdata {
void __iomem *base;
struct clk *atclk;
struct coresight_device *csdev;
spinlock_t spinlock;
+ bool check_idfilter_val;
};
static void dynamic_replicator_reset(struct replicator_drvdata *drvdata)
@@ -66,29 +69,43 @@ static int dynamic_replicator_enable(struct replicator_drvdata *drvdata,
int inport, int outport)
{
int rc = 0;
- u32 reg;
-
- switch (outport) {
- case 0:
- reg = REPLICATOR_IDFILTER0;
- break;
- case 1:
- reg = REPLICATOR_IDFILTER1;
- break;
- default:
- WARN_ON(1);
- return -EINVAL;
- }
+ u32 id0val, id1val;
CS_UNLOCK(drvdata->base);
- if ((readl_relaxed(drvdata->base + REPLICATOR_IDFILTER0) == 0xff) &&
- (readl_relaxed(drvdata->base + REPLICATOR_IDFILTER1) == 0xff))
+ id0val = readl_relaxed(drvdata->base + REPLICATOR_IDFILTER0);
+ id1val = readl_relaxed(drvdata->base + REPLICATOR_IDFILTER1);
+
+ /*
+ * Some replicator designs lose context when AMBA clocks are removed,
+ * so have a check for this.
+ */
+ if (drvdata->check_idfilter_val && id0val == 0x0 && id1val == 0x0)
+ id0val = id1val = 0xff;
+
+ if (id0val == 0xff && id1val == 0xff)
rc = coresight_claim_device_unlocked(drvdata->base);
+ if (!rc) {
+ switch (outport) {
+ case 0:
+ id0val = 0x0;
+ break;
+ case 1:
+ id1val = 0x0;
+ break;
+ default:
+ WARN_ON(1);
+ rc = -EINVAL;
+ }
+ }
+
/* Ensure that the outport is enabled. */
- if (!rc)
- writel_relaxed(0x00, drvdata->base + reg);
+ if (!rc) {
+ writel_relaxed(id0val, drvdata->base + REPLICATOR_IDFILTER0);
+ writel_relaxed(id1val, drvdata->base + REPLICATOR_IDFILTER1);
+ }
+
CS_LOCK(drvdata->base);
return rc;
@@ -239,6 +256,10 @@ static int replicator_probe(struct device *dev, struct resource *res)
desc.groups = replicator_groups;
}
+ if (fwnode_property_present(dev_fwnode(dev),
+ "qcom,replicator-loses-context"))
+ drvdata->check_idfilter_val = true;
+
dev_set_drvdata(dev, drvdata);
pdata = coresight_get_platform_data(dev);
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related
* [PATCHv3 2/2] dt-bindings: arm: coresight: Add optional property to replicators
From: Sai Prakash Ranjan @ 2020-05-22 18:36 UTC (permalink / raw)
To: Mathieu Poirier, Suzuki K Poulose, Mike Leach, devicetree,
Rob Herring
Cc: linux-arm-kernel, linux-kernel, linux-arm-msm, Stephen Boyd,
Sai Prakash Ranjan
In-Reply-To: <cover.1590171891.git.saiprakash.ranjan@codeaurora.org>
Add an optional boolean property "qcom,replicator-loses-context" to
identify replicators which loses context when AMBA clocks are removed
in certain configurable replicator designs.
Reviewed-by: Mike Leach <mike.leach@linaro.org>
Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
---
Documentation/devicetree/bindings/arm/coresight.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/coresight.txt b/Documentation/devicetree/bindings/arm/coresight.txt
index 846f6daae71b..b598a5f0037d 100644
--- a/Documentation/devicetree/bindings/arm/coresight.txt
+++ b/Documentation/devicetree/bindings/arm/coresight.txt
@@ -121,6 +121,12 @@ its hardware characteristcs.
* interrupts : Exactly one SPI may be listed for reporting the address
error
+* Optional property for configurable replicators:
+
+ * qcom,replicator-loses-context: boolean. Indicates that the replicator
+ will lose register context when AMBA clock is removed which is observed
+ in some replicator designs.
+
Graph bindings for Coresight
-------------------------------
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH v2] ARM: dts: r8a7742: Add RWDT node
From: Lad Prabhakar @ 2020-05-22 18:37 UTC (permalink / raw)
To: Geert Uytterhoeven, Magnus Damm, Rob Herring
Cc: linux-renesas-soc, devicetree, linux-kernel, Prabhakar,
Lad Prabhakar
Add a device node for the Watchdog Timer (RWDT) controller on the Renesas
RZ/G1H (r8a7742) SoC.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Hi All,
This patch is part of series [1] ("RZ/G1H describe I2C, IIC, MMC0, SATA,
AVB, RWDT and APMU nodes") as rest of the patches have been acked/reviewed
just re-sending this alone patch.
[1] https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=288491
v1->v2
* Added missing interrupts property
* Included Reviewed-by tags
---
arch/arm/boot/dts/r8a7742.dtsi | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7742.dtsi b/arch/arm/boot/dts/r8a7742.dtsi
index da75767..df914da 100644
--- a/arch/arm/boot/dts/r8a7742.dtsi
+++ b/arch/arm/boot/dts/r8a7742.dtsi
@@ -201,6 +201,17 @@
#size-cells = <2>;
ranges;
+ rwdt: watchdog@e6020000 {
+ compatible = "renesas,r8a7742-wdt",
+ "renesas,rcar-gen2-wdt";
+ reg = <0 0xe6020000 0 0x0c>;
+ interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 402>;
+ power-domains = <&sysc R8A7742_PD_ALWAYS_ON>;
+ resets = <&cpg 402>;
+ status = "disabled";
+ };
+
gpio0: gpio@e6050000 {
compatible = "renesas,gpio-r8a7742",
"renesas,rcar-gen2-gpio";
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next v2 4/4] net: dp83869: Add RGMII internal delay configuration
From: Dan Murphy @ 2020-05-22 18:50 UTC (permalink / raw)
To: Florian Fainelli, andrew, hkallweit1, davem, robh
Cc: netdev, linux-kernel, devicetree
In-Reply-To: <a1ec8ef0-1536-267b-e8f7-9902ed06c883@gmail.com>
Florian
On 5/22/20 11:13 AM, Florian Fainelli wrote:
>
> On 5/22/2020 5:25 AM, Dan Murphy wrote:
>> Add RGMII internal delay configuration for Rx and Tx.
>>
>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>> ---
>> drivers/net/phy/dp83869.c | 101 ++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 101 insertions(+)
>>
>> diff --git a/drivers/net/phy/dp83869.c b/drivers/net/phy/dp83869.c
>> index cfb22a21a2e6..a9008d32e2b6 100644
>> --- a/drivers/net/phy/dp83869.c
>> +++ b/drivers/net/phy/dp83869.c
>> @@ -99,6 +99,14 @@
>> #define DP83869_OP_MODE_MII BIT(5)
>> #define DP83869_SGMII_RGMII_BRIDGE BIT(6)
>>
>> +/* RGMIIDCTL bits */
>> +#define DP83869_RGMII_TX_CLK_DELAY_SHIFT 4
>> +#define DP83869_RGMII_CLK_DELAY_INV 0
>> +
>> +static int dp83869_internal_delay[] = {250, 500, 750, 1000, 1250, 1500, 1750,
>> + 2000, 2250, 2500, 2750, 3000, 3250,
>> + 3500, 3750, 4000};
>> +
>> enum {
>> DP83869_PORT_MIRRORING_KEEP,
>> DP83869_PORT_MIRRORING_EN,
>> @@ -108,6 +116,8 @@ enum {
>> struct dp83869_private {
>> int tx_fifo_depth;
>> int rx_fifo_depth;
>> + u32 rx_id_delay;
>> + u32 tx_id_delay;
>> int io_impedance;
>> int port_mirroring;
>> bool rxctrl_strap_quirk;
>> @@ -182,6 +192,7 @@ static int dp83869_of_init(struct phy_device *phydev)
>> struct dp83869_private *dp83869 = phydev->priv;
>> struct device *dev = &phydev->mdio.dev;
>> struct device_node *of_node = dev->of_node;
>> + int delay_size = ARRAY_SIZE(dp83869_internal_delay);
>> int ret;
>>
>> if (!of_node)
>> @@ -232,6 +243,26 @@ static int dp83869_of_init(struct phy_device *phydev)
>> &dp83869->tx_fifo_depth))
>> dp83869->tx_fifo_depth = DP83869_PHYCR_FIFO_DEPTH_4_B_NIB;
>>
>> + dp83869->rx_id_delay = DP83869_RGMII_CLK_DELAY_INV;
>> + ret = of_property_read_u32(of_node, "rx-internal-delay-ps",
>> + &dp83869->rx_id_delay);
>> + if (!ret && dp83869->rx_id_delay > dp83869_internal_delay[delay_size]) {
>> + phydev_err(phydev,
>> + "rx-internal-delay value of %u out of range\n",
>> + dp83869->rx_id_delay);
>> + return -EINVAL;
>> + }
>> +
>> + dp83869->tx_id_delay = DP83869_RGMII_CLK_DELAY_INV;
>> + ret = of_property_read_u32(of_node, "tx-internal-delay-ps",
>> + &dp83869->tx_id_delay);
>> + if (!ret && dp83869->tx_id_delay > dp83869_internal_delay[delay_size]) {
>> + phydev_err(phydev,
>> + "tx-internal-delay value of %u out of range\n",
>> + dp83869->tx_id_delay);
>> + return -EINVAL;
>> + }
> This is the kind of validation that I would be expecting from the PHY
> library to do, in fact, since you use Device Tree standard property, I
> would expect you only need to pass the maximum delay value and some
> storage for your array of delays.
Actually the PHY library will return either the 0th index if the value
is to small or the max index if the value is to large
based on the array passed in so maybe this check is unnecessary.
>> +
>> return ret;
>> }
>> #else
>> @@ -270,6 +301,29 @@ static int dp83869_configure_rgmii(struct phy_device *phydev,
>> return ret;
>> }
>>
>> +static int dp83869_verify_rgmii_cfg(struct phy_device *phydev)
>> +{
>> + struct dp83869_private *dp83869 = phydev->priv;
>> +
>> + /* RX delay *must* be specified if internal delay of RX is used. */
>> + if ((phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
>> + phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID) &&
>> + dp83869->rx_id_delay == DP83869_RGMII_CLK_DELAY_INV) {
>> + phydev_err(phydev, "ti,rx-internal-delay must be specified\n");
>> + return -EINVAL;
>> + }
>> +
>> + /* TX delay *must* be specified if internal delay of TX is used. */
>> + if ((phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
>> + phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID) &&
>> + dp83869->tx_id_delay == DP83869_RGMII_CLK_DELAY_INV) {
>> + phydev_err(phydev, "ti,tx-internal-delay must be specified\n");
>> + return -EINVAL;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> static int dp83869_configure_mode(struct phy_device *phydev,
>> struct dp83869_private *dp83869)
>> {
>> @@ -371,6 +425,12 @@ static int dp83869_config_init(struct phy_device *phydev)
>> {
>> struct dp83869_private *dp83869 = phydev->priv;
>> int ret, val;
>> + int delay_size = ARRAY_SIZE(dp83869_internal_delay);
>> + int delay = 0;
>> +
>> + ret = dp83869_verify_rgmii_cfg(phydev);
>> + if (ret)
>> + return ret;
>>
>> ret = dp83869_configure_mode(phydev, dp83869);
>> if (ret)
>> @@ -394,6 +454,47 @@ static int dp83869_config_init(struct phy_device *phydev)
>> dp83869->clk_output_sel <<
>> DP83869_IO_MUX_CFG_CLK_O_SEL_SHIFT);
>>
>> + if (phy_interface_is_rgmii(phydev)) {
>> + val = phy_read_mmd(phydev, DP83869_DEVADDR, DP83869_RGMIICTL);
>> +
>> + val &= ~(DP83869_RGMII_TX_CLK_DELAY_EN | DP83869_RGMII_RX_CLK_DELAY_EN);
>> + if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)
>> + val |= (DP83869_RGMII_TX_CLK_DELAY_EN | DP83869_RGMII_RX_CLK_DELAY_EN);
>> +
>> + if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID)
>> + val |= DP83869_RGMII_TX_CLK_DELAY_EN;
>> +
>> + if (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID)
>> + val |= DP83869_RGMII_RX_CLK_DELAY_EN;
>> +
>> + phy_write_mmd(phydev, DP83869_DEVADDR, DP83869_RGMIICTL, val);
>> +
>> + if (dp83869->rx_id_delay) {
>> + val = phy_get_delay_index(phydev,
>> + &dp83869_internal_delay[0],
>> + delay_size,
>> + dp83869->rx_id_delay);
>> + if (val < 0)
>> + return val;
>> +
>> + delay |= val;
> Don't you need to do a bitwise AND with the maximum delay value
> supported by the range since you do a Read/Modify/Write operation here?
There is not RMW here. This is a write to the RGMIIDCTL register.
>
>> + }
>> +
>> + if (dp83869->tx_id_delay) {
>> + val = phy_get_delay_index(phydev,
>> + &dp83869_internal_delay[0],
>> + delay_size,
>> + dp83869->tx_id_delay);
>> + if (val < 0)
>> + return val;
>> +
>> + delay |= val << DP83869_RGMII_TX_CLK_DELAY_SHIFT;
> Likewise.
Same as above
Dan
^ permalink raw reply
* Re: [PATCH V6 2/7] soc: qcom-geni-se: Add interconnect support to fix earlycon crash
From: kbuild test robot @ 2020-05-22 18:31 UTC (permalink / raw)
To: Akash Asthana, gregkh, agross, bjorn.andersson, wsa, broonie,
mark.rutland, robh+dt
Cc: kbuild-all, clang-built-linux, linux-i2c, linux-spi, devicetree,
swboyd, mgautam, linux-arm-msm, linux-serial, mka, dianders
In-Reply-To: <1590049764-20912-3-git-send-email-akashast@codeaurora.org>
[-- Attachment #1: Type: text/plain, Size: 4422 bytes --]
Hi Akash,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on tty/tty-testing]
[also build test ERROR on spi/for-next wsa/i2c/for-next usb/usb-testing driver-core/driver-core-testing linus/master v5.7-rc6]
[cannot apply to next-20200522]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Akash-Asthana/Add-interconnect-support-to-QSPI-and-QUP-drivers/20200521-163523
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tty-testing
config: x86_64-randconfig-r023-20200521 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 3393cc4cebf9969db94dc424b7a2b6195589c33b)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
All error/warnings (new ones prefixed by >>, old ones prefixed by <<):
drivers/soc/qcom/qcom-geni-se.c:739:27: error: implicit declaration of function 'devm_of_icc_get' [-Werror,-Wimplicit-function-declaration]
se->icc_paths[i].path = devm_of_icc_get(se->dev, icc_names[i]);
^
drivers/soc/qcom/qcom-geni-se.c:739:27: note: did you mean 'of_icc_get'?
include/linux/interconnect.h:30:18: note: 'of_icc_get' declared here
struct icc_path *of_icc_get(struct device *dev, const char *name);
^
drivers/soc/qcom/qcom-geni-se.c:739:25: warning: incompatible integer to pointer conversion assigning to 'struct icc_path *' from 'int' [-Wint-conversion]
se->icc_paths[i].path = devm_of_icc_get(se->dev, icc_names[i]);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/soc/qcom/qcom-geni-se.c:790:9: error: implicit declaration of function 'icc_enable' [-Werror,-Wimplicit-function-declaration]
ret = icc_enable(se->icc_paths[i].path);
^
drivers/soc/qcom/qcom-geni-se.c:807:9: error: implicit declaration of function 'icc_disable' [-Werror,-Wimplicit-function-declaration]
ret = icc_disable(se->icc_paths[i].path);
^
>> drivers/soc/qcom/qcom-geni-se.c:829:11: error: implicit declaration of function 'of_get_next_parent' [-Werror,-Wimplicit-function-declaration]
parent = of_get_next_parent(wrapper->dev->of_node);
^
>> drivers/soc/qcom/qcom-geni-se.c:829:9: warning: incompatible integer to pointer conversion assigning to 'struct device_node *' from 'int' [-Wint-conversion]
parent = of_get_next_parent(wrapper->dev->of_node);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/soc/qcom/qcom-geni-se.c:883:26: error: implicit declaration of function 'devm_of_icc_get' [-Werror,-Wimplicit-function-declaration]
wrapper->to_core.path = devm_of_icc_get(dev, "qup-core");
^
drivers/soc/qcom/qcom-geni-se.c:883:24: warning: incompatible integer to pointer conversion assigning to 'struct icc_path *' from 'int' [-Wint-conversion]
wrapper->to_core.path = devm_of_icc_get(dev, "qup-core");
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3 warnings and 5 errors generated.
vim +/of_get_next_parent +829 drivers/soc/qcom/qcom-geni-se.c
818
819 void geni_remove_earlycon_icc_vote(void)
820 {
821 struct geni_wrapper *wrapper;
822 struct device_node *parent;
823 struct device_node *child;
824
825 if (!earlycon_wrapper)
826 return;
827
828 wrapper = earlycon_wrapper;
> 829 parent = of_get_next_parent(wrapper->dev->of_node);
830 for_each_child_of_node(parent, child) {
831 if (!of_device_is_compatible(child, "qcom,geni-se-qup"))
832 continue;
833 wrapper = platform_get_drvdata(of_find_device_by_node(child));
834 icc_put(wrapper->to_core.path);
835 wrapper->to_core.path = NULL;
836
837 }
838 of_node_put(parent);
839
840 earlycon_wrapper = NULL;
841 }
842 EXPORT_SYMBOL(geni_remove_earlycon_icc_vote);
843
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 35395 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] remoteproc: add support for a new 64-bit trace version
From: Suman Anna @ 2020-05-22 18:59 UTC (permalink / raw)
To: Clément Leger, Bjorn Andersson
Cc: Rob Herring, Mathieu Poirier, Loic PALLARDY, Arnaud Pouliquen,
Lokesh Vutla, linux-remoteproc, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <1334263091.4218509.1590171014972.JavaMail.zimbra@kalray.eu>
Hi Clement,
> > ----- On 22 May, 2020, at 20:03, Clément Leger cleger@kalray.eu wrote:>
>> Hi Suman,
>>
>> ----- On 22 May, 2020, at 19:33, Bjorn Andersson bjorn.andersson@linaro.org
>> wrote:
>>
>>> On Fri 22 May 09:54 PDT 2020, Suman Anna wrote:
>>>
>>>> On 5/21/20 2:42 PM, Suman Anna wrote:
>>>>> Hi Bjorn,
>>>>>
>>>>> On 5/21/20 1:04 PM, Bjorn Andersson wrote:
>>>>>> On Wed 25 Mar 13:47 PDT 2020, Suman Anna wrote:
>>> [..]
>>>>>>> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
>>> [..]
>>>>>>> +struct fw_rsc_trace2 {
>>>>>>
>>>>>> Sounds more like fw_rsc_trace64 to me - in particular since the version
>>>>>> of trace2 is 1...
>>>>>
>>>>> Yeah, will rename this.
>>>>>
>>>>>>
>>>>>>> + u32 padding;
>>>>>>> + u64 da;
>>>>>>> + u32 len;
>>>>>>> + u32 reserved;
>>>>>>
>>>>>> What's the purpose of this reserved field?
>>>>>
>>>>> Partly to make sure the entire resource is aligned on an 8-byte, and
>>>>> partly copied over from fw_rsc_trace entry. I guess 32-bits is already
>>>>> large enough of a size for trace entries irrespective of 32-bit or
>>>>> 64-bit traces, so I doubt if we want to make the len field also a u64.
>>>>
>>>> Looking at this again, I can drop both padding and reserved fields, if I
>>>> move the len field before da. Any preferences/comments?
>>
> Sorry, my message went a bit too fast... So as I was saying:
>
> Not only the in-structure alignment matters but also in the resource table.
> Since the resource table is often packed (see [1] for instance), if a trace
> resource is embedded in the resource table after another resource aligned
> on 32 bits only, your 64 bits trace field will potentially end up
> misaligned.
Right. Since one can mix and match the resources of different sizes and
include them in any order, the onus is going to be on the resource table
constructors to ensure the inter-resource alignments, if any are
required. The resource table format allows you to add padding fields in
between if needed, and the remoteproc core relies on the offsets.
I can only ensure the alignment within this resource structure with
ready-available access and conversion to/from a 64-bit type, as long as
the resource is starting on a 64-bit boundary.
>
> To overcome this, there is multiple solutions:
>
> - Split the 64 bits fields into 32bits low and high parts:
> Since all resources are aligned on 32bits, it will be ok
Yes, this is one solution. At the same time, this means you need
additional conversion logic for converting to and from 64-bit field. In
this particular case, da is the address of the trace buffer pointer on a
64-bit processor, so we can directly use the address of the trace
buffer. Guess it is a question of easier translation vs packing the
resource table as tight as possible.
>
> - Use memcpy_from/to_io when reading/writing such fields
> As I said in a previous message this should probably be used since
> the memories that are accessed by rproc are io mem (ioremap in almost
> all drivers).
Anything running out of DDR actually doesn't need the io mem semantics,
so we actually need to be fixing the drivers. Blindly changing the
current memcpy to memcpy_to_io in the core loader is also not right. Any
internal memories properties will actually depend on the processor and
SoC. Eg: The R5 TCM interfaces in general can be treated as normal memories.
regards
Suman
>
> Regards,
>
> Clément
>
> [1] https://github.com/OpenAMP/open-amp/blob/master/apps/machine/zynqmp_r5/rsc_table.h
>>
>>
>>
>>
>>>>
>>>
>>> Sounds good to me.
>>>
>>> Thanks,
>>> Bjorn
^ permalink raw reply
* Re: [RESEND PATCH] thermal: mediatek: add suspend/resume callback
From: Daniel Lezcano @ 2020-05-22 19:08 UTC (permalink / raw)
To: Michael Kao, Zhang Rui, Eduardo Valentin, Rob Herring,
Mark Rutland, Matthias Brugger, hsinyi, linux-pm, srv_heupstream
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
Louis Yu
In-Reply-To: <20200408090558.12410-2-michael.kao@mediatek.com>
On 08/04/2020 11:05, Michael Kao wrote:
> From: Louis Yu <louis.yu@mediatek.com>
>
> Add suspend/resume callback to disable/enable Mediatek thermal sensor
> respectively. Since thermal power domain is off in suspend, thermal driver
> needs re-initialization during resume.
>
> Signed-off-by: Louis Yu <louis.yu@mediatek.com>
> Signed-off-by: Michael Kao <michael.kao@mediatek.com>
[ ... ]
> +static int __maybe_unused mtk_thermal_suspend(struct device *dev)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + struct mtk_thermal *mt = platform_get_drvdata(pdev);
> + int i, ret;
> +
Why is there a multi-controller loop in the probe and resume functions
and not here?
> + for (i = 0; i < mt->conf->num_banks; i++) {
> + ret = mtk_thermal_disable_sensing(mt, i);
> + if (ret)
> + goto out;
> + }
> +
> + /* disable buffer */
> + writel(readl(mt->apmixed_base + APMIXED_SYS_TS_CON1) |
> + APMIXED_SYS_TS_CON1_BUFFER_OFF,
> + mt->apmixed_base + APMIXED_SYS_TS_CON1);
> +
> + clk_disable_unprepare(mt->clk_peri_therm);
> + clk_disable_unprepare(mt->clk_auxadc);
> +
> + return 0;
> +
> +out:
> + dev_err(&pdev->dev, "Failed to wait until bus idle\n");
> +
> + return ret;
> +}
> +
> +static int __maybe_unused mtk_thermal_resume(struct device *dev)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + struct mtk_thermal *mt = platform_get_drvdata(pdev);
> + int i, ret, ctrl_id;
> +
> + ret = device_reset(&pdev->dev);
> + if (ret)
> + return ret;
> +
> + ret = clk_prepare_enable(mt->clk_auxadc);
> + if (ret) {
> + dev_err(&pdev->dev, "Can't enable auxadc clk: %d\n", ret);
> + goto err_disable_clk_auxadc;
> + }
> +
> + ret = clk_prepare_enable(mt->clk_peri_therm);
> + if (ret) {
> + dev_err(&pdev->dev, "Can't enable peri clk: %d\n", ret);
> + goto err_disable_clk_peri_therm;
> + }
> +
> + for (ctrl_id = 0; ctrl_id < mt->conf->num_controller ; ctrl_id++)
> + for (i = 0; i < mt->conf->num_banks; i++)
> + mtk_thermal_init_bank(mt, i, mt->apmixed_phys_base,
> + mt->auxadc_phys_base, ctrl_id);
> +
> + return 0;
> +
> +err_disable_clk_peri_therm:
> + clk_disable_unprepare(mt->clk_peri_therm);
> +err_disable_clk_auxadc:
> + clk_disable_unprepare(mt->clk_auxadc);
> +
> + return ret;
> +}
> +
> +static SIMPLE_DEV_PM_OPS(mtk_thermal_pm_ops,
> + mtk_thermal_suspend, mtk_thermal_resume);
> +
> static struct platform_driver mtk_thermal_driver = {
> .probe = mtk_thermal_probe,
> .remove = mtk_thermal_remove,
> .driver = {
> .name = "mtk-thermal",
> + .pm = &mtk_thermal_pm_ops,
> .of_match_table = mtk_thermal_of_match,
> },
> };
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* Re: [PATCH 03/17] ARM: dts: r8a7742: Add I2C and IIC support
From: Lad, Prabhakar @ 2020-05-22 19:14 UTC (permalink / raw)
To: Wolfram Sang
Cc: Geert Uytterhoeven, Lad Prabhakar, Jens Axboe, Rob Herring,
Ulf Hansson, Sergei Shtylyov, David S. Miller, Wim Van Sebroeck,
Guenter Roeck, linux-ide,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, LKML,
Linux I2C, Linux MMC List, netdev, Linux-Renesas,
Linux Watchdog Mailing List
In-Reply-To: <CAMuHMdVWe1EEAtP64VW+0zXNingM1LiENv_Rfz5qTQ+C0dtGSw@mail.gmail.com>
Hi Wolfram,
On Mon, May 18, 2020 at 11:10 AM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
>
> Hi Wolfram,
>
> On Mon, May 18, 2020 at 11:26 AM Wolfram Sang
> <wsa+renesas@sang-engineering.com> wrote:
> > > > However, both versions (with and without automatic transmission) are
> > > > described with the same "renesas,iic-r8a7742" compatible. Is it possible
> > > > to detect the reduced variant at runtime somehow?
> > > >
> > > I couldn't find anything the manual that would be useful to detect at runtime.
>
> Hence if we really need that (see below), we need a quirk based on compatible
> value + base address.
>
> > > > My concern is that the peculiarity of this SoC might be forgotten if we
> > > > describe it like this and ever add "automatic transmissions" somewhen.
> > > >
> > > Agreed.
> >
> > Well, I guess reading from a register which is supposed to not be there
> > on the modified IP core is too hackish.
>
> According to the Hardware User's Manual Rev. 1.00, the registers do exist
> on all RZ/G1, except for RZ/G1E (see below).
>
> "(automatic transmission can be used as a hardware function, but this is
> not meaningful for actual use cases)."
>
> (whatever that comment may mean?)
>
> > Leaves us with a seperate compatible entry for it?
>
> On R-Car E3 and RZ/G2E, which have a single IIC instance, we
> handled that by:
>
> The r8a77990 (R-Car E3) and r8a774c0 (RZ/G2E)
> controllers are not considered compatible with
> "renesas,rcar-gen3-iic" or "renesas,rmobile-iic"
> due to the absence of automatic transmission registers.
>
> On R-Car E2 and RZ/G1E, we forgot, and used both SoC-specific and
> family-specific compatible values.
>
What are your thoughts on the above.
Cheers,
--Prabhakar
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
^ permalink raw reply
* Re: [v2 1/2] dts: ppc: t4240rdb: remove interrupts property
From: Li Yang @ 2020-05-22 19:20 UTC (permalink / raw)
To: Biwen Li
Cc: Rob Herring, Michael Ellerman, Benjamin Herrenschmidt, a.zummo,
Alexandre Belloni,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linuxppc-dev, lkml, linux-rtc, Biwen Li
In-Reply-To: <20200520091543.44692-1-biwen.li@oss.nxp.com>
On Wed, May 20, 2020 at 4:21 AM Biwen Li <biwen.li@oss.nxp.com> wrote:
>
> From: Biwen Li <biwen.li@nxp.com>
>
> This removes interrupts property to drop warning as follows:
> - $ hwclock.util-linux
> hwclock.util-linux: select() to /dev/rtc0
> to wait for clock tick timed out
>
> My case:
> - RTC ds1374's INT pin is connected to VCC on T4240RDB,
> then the RTC cannot inform cpu about the alarm interrupt
The commit message need a little bit improvement. Something like:
Since the interrupt pin for RTC DS1374 is not connected to the CPU on
T4240RDB, remove
the interrupt property from the device tree.
This also fix the following warning for hwclock.util-linux:
$ hwclock.util-linux
hwclock.util-linux: select() to /dev/rtc0
to wait for clock tick timed out
>
> Signed-off-by: Biwen Li <biwen.li@nxp.com>
> ---
> arch/powerpc/boot/dts/fsl/t4240rdb.dts | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/powerpc/boot/dts/fsl/t4240rdb.dts b/arch/powerpc/boot/dts/fsl/t4240rdb.dts
> index a56a705d41f7..145896f2eef6 100644
> --- a/arch/powerpc/boot/dts/fsl/t4240rdb.dts
> +++ b/arch/powerpc/boot/dts/fsl/t4240rdb.dts
> @@ -144,7 +144,6 @@
> rtc@68 {
> compatible = "dallas,ds1374";
> reg = <0x68>;
> - interrupts = <0x1 0x1 0 0>;
> };
> };
>
> --
> 2.17.1
>
^ permalink raw reply
* Re: [v2 2/2] dts: ppc: t1024rdb: remove interrupts property
From: Li Yang @ 2020-05-22 19:22 UTC (permalink / raw)
To: Biwen Li
Cc: Rob Herring, Michael Ellerman, Benjamin Herrenschmidt, a.zummo,
Alexandre Belloni,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linuxppc-dev, lkml, linux-rtc, Biwen Li
In-Reply-To: <20200520091543.44692-2-biwen.li@oss.nxp.com>
On Wed, May 20, 2020 at 4:21 AM Biwen Li <biwen.li@oss.nxp.com> wrote:
>
> From: Biwen Li <biwen.li@nxp.com>
>
> This removes interrupts property to drop warning as follows:
> - $ hwclock.util-linux
> hwclock.util-linux: select() to /dev/rtc0
> to wait for clock tick timed out
>
> My case:
> - RTC ds1339s INT pin isn't connected to cpus INT pin on T1024RDB,
> then the RTC cannot inform cpu about alarm interrupt
>
> How to fix it?
> - remove IRQ line
This style is not the recommended style for commit message. Please
see my comment for the other patch.
>
> Signed-off-by: Biwen Li <biwen.li@nxp.com>
> ---
> arch/powerpc/boot/dts/fsl/t1024rdb.dts | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/powerpc/boot/dts/fsl/t1024rdb.dts b/arch/powerpc/boot/dts/fsl/t1024rdb.dts
> index 645caff98ed1..605ceec66af3 100644
> --- a/arch/powerpc/boot/dts/fsl/t1024rdb.dts
> +++ b/arch/powerpc/boot/dts/fsl/t1024rdb.dts
> @@ -161,7 +161,6 @@
> rtc@68 {
> compatible = "dallas,ds1339";
> reg = <0x68>;
> - interrupts = <0x1 0x1 0 0>;
> };
> };
>
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH 3/4] remoteproc: add support for a new 64-bit trace version
From: Clément Leger @ 2020-05-22 19:28 UTC (permalink / raw)
To: s-anna
Cc: Bjorn Andersson, Rob Herring, Mathieu Poirier, Loic PALLARDY,
Arnaud Pouliquen, Lokesh Vutla, linux-remoteproc, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <4fab212b-a9d2-927e-d3d7-e591912fd6cf@ti.com>
Hi Suman,
----- On 22 May, 2020, at 20:59, s-anna s-anna@ti.com wrote:
> Hi Clement,
>
>> > ----- On 22 May, 2020, at 20:03, Clément Leger cleger@kalray.eu wrote:>
>>> Hi Suman,
>>>
>>> ----- On 22 May, 2020, at 19:33, Bjorn Andersson bjorn.andersson@linaro.org
>>> wrote:
>>>
>>>> On Fri 22 May 09:54 PDT 2020, Suman Anna wrote:
>>>>
>>>>> On 5/21/20 2:42 PM, Suman Anna wrote:
>>>>>> Hi Bjorn,
>>>>>>
>>>>>> On 5/21/20 1:04 PM, Bjorn Andersson wrote:
>>>>>>> On Wed 25 Mar 13:47 PDT 2020, Suman Anna wrote:
>>>> [..]
>>>>>>>> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
>>>> [..]
>>>>>>>> +struct fw_rsc_trace2 {
>>>>>>>
>>>>>>> Sounds more like fw_rsc_trace64 to me - in particular since the version
>>>>>>> of trace2 is 1...
>>>>>>
>>>>>> Yeah, will rename this.
>>>>>>
>>>>>>>
>>>>>>>> + u32 padding;
>>>>>>>> + u64 da;
>>>>>>>> + u32 len;
>>>>>>>> + u32 reserved;
>>>>>>>
>>>>>>> What's the purpose of this reserved field?
>>>>>>
>>>>>> Partly to make sure the entire resource is aligned on an 8-byte, and
>>>>>> partly copied over from fw_rsc_trace entry. I guess 32-bits is already
>>>>>> large enough of a size for trace entries irrespective of 32-bit or
>>>>>> 64-bit traces, so I doubt if we want to make the len field also a u64.
>>>>>
>>>>> Looking at this again, I can drop both padding and reserved fields, if I
>>>>> move the len field before da. Any preferences/comments?
>>>
>> Sorry, my message went a bit too fast... So as I was saying:
>>
>> Not only the in-structure alignment matters but also in the resource table.
>> Since the resource table is often packed (see [1] for instance), if a trace
>> resource is embedded in the resource table after another resource aligned
>> on 32 bits only, your 64 bits trace field will potentially end up
>> misaligned.
>
> Right. Since one can mix and match the resources of different sizes and
> include them in any order, the onus is going to be on the resource table
> constructors to ensure the inter-resource alignments, if any are
> required. The resource table format allows you to add padding fields in
> between if needed, and the remoteproc core relies on the offsets.
Agreed
>
> I can only ensure the alignment within this resource structure with
> ready-available access and conversion to/from a 64-bit type, as long as
> the resource is starting on a 64-bit boundary.
>
>>
>> To overcome this, there is multiple solutions:
>>
>> - Split the 64 bits fields into 32bits low and high parts:
>> Since all resources are aligned on 32bits, it will be ok
>
> Yes, this is one solution. At the same time, this means you need
> additional conversion logic for converting to and from 64-bit field. In
> this particular case, da is the address of the trace buffer pointer on a
> 64-bit processor, so we can directly use the address of the trace
> buffer. Guess it is a question of easier translation vs packing the
> resource table as tight as possible.
You simply have to add two wrapper such as the following:
static inline void rproc_rsc_set_addr(u32 *low, u32 *hi, u64 val)
{
*low = lower_32_bits(val);
*hi = upper_32_bits(val);
}
static inline u64 rproc_rsc_get_addr(u32 low, u32 hi)
{
return ((u64) hi << 32) | low;
}
This is not really difficult to use and will ensure your new trace
resource can be used easily without breaking 32 bits alignment.
Breaking compatibility is an option also and it is probably needed
to document it clearly if it is chosen to do so.
>
>>
>> - Use memcpy_from/to_io when reading/writing such fields
>> As I said in a previous message this should probably be used since
>> the memories that are accessed by rproc are io mem (ioremap in almost
>> all drivers).
>
> Anything running out of DDR actually doesn't need the io mem semantics,
> so we actually need to be fixing the drivers. Blindly changing the
> current memcpy to memcpy_to_io in the core loader is also not right. Any
> internal memories properties will actually depend on the processor and
> SoC. Eg: The R5 TCM interfaces in general can be treated as normal memories.
Agreed, this is most of the case indeed where the memories are actually
accessible directly. But using ioremap potentially creates a mapping that
does not support misaligned accesses and so accesses should be always aligned.
memcpy_from/to_io ensures that.
IMHO, there is probably something to be rework since the drivers are mapping
the memories but the core is accessing this memory, knowing nothing about
how it was mapped.
Regards,
Clément
>
> regards
> Suman
>
>>
>> Regards,
>>
>> Clément
>>
>> [1]
>> https://github.com/OpenAMP/open-amp/blob/master/apps/machine/zynqmp_r5/rsc_table.h
>>>
>>>
>>>
>>>
>>>>>
>>>>
>>>> Sounds good to me.
>>>>
>>>> Thanks,
> >>> Bjorn
^ permalink raw reply
* Re: [PATCH] dt-bindings: timer: Add renesas,em-sti bindings
From: Daniel Lezcano @ 2020-05-22 19:38 UTC (permalink / raw)
To: Geert Uytterhoeven, Thomas Gleixner, Rob Herring, Magnus Damm
Cc: devicetree, linux-renesas-soc, linux-kernel
In-Reply-To: <20200519081101.28973-1-geert+renesas@glider.be>
On 19/05/2020 10:11, Geert Uytterhoeven wrote:
> Document Device Tree bindings for the Renesas EMMA Mobile System Timer.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
Applied, thanks
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* Re: [PATCH v3 2/2] arm64: dts: Add ds26522 node to dts to ls1043ardb
From: Li Yang @ 2020-05-22 19:38 UTC (permalink / raw)
To: Qiang Zhao
Cc: Shawn Guo,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, lkml
In-Reply-To: <20200520040221.10536-2-qiang.zhao@nxp.com>
On Tue, May 19, 2020 at 11:08 PM Qiang Zhao <qiang.zhao@nxp.com> wrote:
>
> From: Zhao Qiang <qiang.zhao@nxp.com>
Maybe remove the duplicated dts in the title?
>
> Add ds26522 node to fsl-ls1043a-rdb.dts
>
> Signed-off-by: Zhao Qiang <qiang.zhao@nxp.com>
> ---
> v3:
> - use "arm64: dts:" format for subject
>
> arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
> index 44d9343..1cb265f 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
> @@ -94,6 +94,22 @@
> reg = <0>;
> spi-max-frequency = <1000000>; /* input clock */
> };
> +
> + slic@2 {
If this is a plugin card for the board, will this cause any problem
when the card is not plugged in?
> + compatible = "maxim,ds26522";
> + reg = <2>;
> + spi-max-frequency = <2000000>;
> + fsl,spi-cs-sck-delay = <100>;
> + fsl,spi-sck-cs-delay = <50>;
> + };
> +
> + slic@3 {
> + compatible = "maxim,ds26522";
> + reg = <3>;
> + spi-max-frequency = <2000000>;
> + fsl,spi-cs-sck-delay = <100>;
> + fsl,spi-sck-cs-delay = <50>;
> + };
> };
>
> &duart0 {
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH 03/17] ARM: dts: r8a7742: Add I2C and IIC support
From: Wolfram Sang @ 2020-05-22 20:17 UTC (permalink / raw)
To: Lad, Prabhakar
Cc: Geert Uytterhoeven, Lad Prabhakar, Jens Axboe, Rob Herring,
Ulf Hansson, Sergei Shtylyov, David S. Miller, Wim Van Sebroeck,
Guenter Roeck, linux-ide,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, LKML,
Linux I2C, Linux MMC List, netdev, Linux-Renesas,
Linux Watchdog Mailing List
In-Reply-To: <CA+V-a8tVx6D8Vh=rYD2=Z-14GAW0puo009FtjYM++sw8PAtJug@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1215 bytes --]
> > According to the Hardware User's Manual Rev. 1.00, the registers do exist
> > on all RZ/G1, except for RZ/G1E (see below).
> >
> > "(automatic transmission can be used as a hardware function, but this is
> > not meaningful for actual use cases)."
> >
> > (whatever that comment may mean?)
Strange comment, in deed. Given the paragraph before, I would guess Gen1
maybe had a "fitting" PMIC where SoC/PMIC handled DVFS kind of magically
with this automatic transfer feature? And Gen2 has not.
> > On R-Car E3 and RZ/G2E, which have a single IIC instance, we
> > handled that by:
> >
> > The r8a77990 (R-Car E3) and r8a774c0 (RZ/G2E)
> > controllers are not considered compatible with
> > "renesas,rcar-gen3-iic" or "renesas,rmobile-iic"
> > due to the absence of automatic transmission registers.
From a "describe the HW" point of view, this still makes sense to me.
Although, it is unlikely we will add support for the automatic
transmission feature (maybe famous last words).
> > On R-Car E2 and RZ/G1E, we forgot, and used both SoC-specific and
> > family-specific compatible values.
Okay, but we can fix DTs when they have bugs, or?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v5 00/11] mediatek: add support for MediaTek Ethernet MAC
From: David Miller @ 2020-05-22 21:20 UTC (permalink / raw)
To: brgl
Cc: robh+dt, matthias.bgg, john, sean.wang, Mark-MC.Lee, kuba, arnd,
fparent, hkallweit1, edwin.peer, devicetree, linux-kernel, netdev,
linux-arm-kernel, linux-mediatek, stephane.leprovost, pedro.tsai,
andrew.perepech, bgolaszewski
In-Reply-To: <20200522120700.838-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <brgl@bgdev.pl>
Date: Fri, 22 May 2020 14:06:49 +0200
> This series adds support for the STAR Ethernet Controller present on MediaTeK
> SoCs from the MT8* family.
Series applied to net-next, thank you.
^ permalink raw reply
* Re: [soc:mediatek/dt] BUILD REGRESSION 189881af810d452b592ee958db43eb4c57df9803
From: Arnd Bergmann @ 2020-05-22 21:24 UTC (permalink / raw)
To: Matthias Brugger; +Cc: kbuild test robot, arm-soc, Linux ARM, DTML
In-Reply-To: <5c53e7b7-4caa-06b9-8a9f-b3a29f008bb7@gmail.com>
On Fri, May 22, 2020 at 10:54 PM Matthias Brugger
<matthias.bgg@gmail.com> wrote:
>
> Hi all,
> Hi Arnd and Olof,
>
> On 22/05/2020 13:28, kbuild test robot wrote:
> > tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git mediatek/dt
> > branch HEAD: 189881af810d452b592ee958db43eb4c57df9803 arm: dts: mt2701: Add usb2 device nodes
> >
> > Error/Warning in current branch:
> >
> > ERROR: Input tree has errors, aborting (use -f to force output)
> >
> > Error/Warning ids grouped by kconfigs:
> >
> > recent_errors
> > `-- arm-randconfig-r035-20200520
> > `-- ERROR:Input-tree-has-errors-aborting-(use-f-to-force-output)
>
> Can you please explain me how to reproduce this. I'm not able to deduce that
> form this email. I can then look into this and how to fix it. Although up to now
> I don't understand where the relation with my dts32 changes is.
I don't see it either here, adding the devicetree list, in case anyone has more
information.
Arnd
^ permalink raw reply
* Re: [PATCH v5 00/11] mediatek: add support for MediaTek Ethernet MAC
From: Matthias Brugger @ 2020-05-22 21:31 UTC (permalink / raw)
To: David Miller, brgl
Cc: robh+dt, john, sean.wang, Mark-MC.Lee, kuba, arnd, fparent,
hkallweit1, edwin.peer, devicetree, linux-kernel, netdev,
linux-arm-kernel, linux-mediatek, stephane.leprovost, pedro.tsai,
andrew.perepech, bgolaszewski
In-Reply-To: <20200522.142031.1631406151370247419.davem@davemloft.net>
On 22/05/2020 23:20, David Miller wrote:
> From: Bartosz Golaszewski <brgl@bgdev.pl>
> Date: Fri, 22 May 2020 14:06:49 +0200
>
>> This series adds support for the STAR Ethernet Controller present on MediaTeK
>> SoCs from the MT8* family.
>
> Series applied to net-next, thank you.
>
If you say "series applied" do you mean you also applied the device tree parts?
These should go through my branch, because there could be conflicts if there are
other device tree patches from other series, not related with network, touching
the same files.
Regards,
Matthias
^ permalink raw reply
* Re: [PATCH v2 2/2] remoteproc/k3-dsp: Add support for C71x DSPs
From: Mathieu Poirier @ 2020-05-22 21:33 UTC (permalink / raw)
To: Suman Anna
Cc: Bjorn Andersson, Rob Herring, Lokesh Vutla, linux-remoteproc,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20200521151636.28260-3-s-anna@ti.com>
On Thu, May 21, 2020 at 10:16:36AM -0500, Suman Anna wrote:
> The Texas Instrument's K3 J721E SoCs have a newer next-generation
> C71x DSP Subsystem in the MAIN voltage domain in addition to the
> previous generation C66x DSP subsystems. The C71x DSP subsystem is
> based on the TMS320C71x DSP CorePac module. The C71x CPU is a true
> 64-bit machine including 64-bit memory addressing and single-cycle
> 64-bit base arithmetic operations and supports vector signal processing
> providing a significant lift in DSP processing power over C66x DSPs.
> J721E SoCs use a C711 (a one-core 512-bit vector width CPU core) DSP
> that is cache coherent with the A72 Arm cores.
>
> Each subsystem has one or more Fixed/Floating-Point DSP CPUs, with 32 KB
> of L1P Cache, 48 KB of L1D SRAM that can be configured and partitioned as
> either RAM and/or Cache, and 512 KB of L2 SRAM configurable as either RAM
> and/or Cache. The CorePac also includes a Matrix Multiplication Accelerator
> (MMA), a Stream Engine (SE) and a C71x Memory Management Unit (CMMU), an
> Interrupt Controller (INTC) and a Powerdown Management Unit (PMU) modules.
>
> Update the existing K3 DSP remoteproc driver to add support for this C71x
> DSP subsystem. The firmware loading support is provided by using the newly
> added 64-bit ELF loader support, and is limited to images using only
> external DDR memory at the moment. The L1D and L2 SRAMs are used as scratch
> memory when using as RAMs, and cannot be used for loadable segments. The
> CMMU is also not supported to begin with, and the driver is designed to
> treat the MMU as if it is in bypass mode.
>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> ---
> v2:
> - k3_dsp_rproc_prepare/unprepare plugged in dynamically based on local reset,
> C71x doesn't use local resets
> - Dropped the sanity_check ops override, not needed on latest codebase
> v1: https://patchwork.kernel.org/patch/11458595/
>
> drivers/remoteproc/ti_k3_dsp_remoteproc.c | 20 ++++++++++++++++++--
> 1 file changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/remoteproc/ti_k3_dsp_remoteproc.c b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> index 610fbbf85ee6..2dbed316b6ac 100644
> --- a/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> +++ b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> @@ -406,8 +406,6 @@ static void *k3_dsp_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
> }
>
> static const struct rproc_ops k3_dsp_rproc_ops = {
> - .prepare = k3_dsp_rproc_prepare,
> - .unprepare = k3_dsp_rproc_unprepare,
> .start = k3_dsp_rproc_start,
> .stop = k3_dsp_rproc_stop,
> .kick = k3_dsp_rproc_kick,
> @@ -617,6 +615,10 @@ static int k3_dsp_rproc_probe(struct platform_device *pdev)
>
> rproc->has_iommu = false;
> rproc->recovery_disabled = true;
> + if (data->uses_lreset) {
> + rproc->ops->prepare = k3_dsp_rproc_prepare;
> + rproc->ops->unprepare = k3_dsp_rproc_unprepare;
> + }
Yes
> kproc = rproc->priv;
> kproc->rproc = rproc;
> kproc->dev = dev;
> @@ -744,6 +746,12 @@ static const struct k3_dsp_mem_data c66_mems[] = {
> { .name = "l1dram", .dev_addr = 0xf00000 },
> };
>
> +/* C71x cores only have a L1P Cache, there are no L1P SRAMs */
> +static const struct k3_dsp_mem_data c71_mems[] = {
> + { .name = "l2sram", .dev_addr = 0x800000 },
> + { .name = "l1dram", .dev_addr = 0xe00000 },
> +};
> +
> static const struct k3_dsp_dev_data c66_data = {
> .mems = c66_mems,
> .num_mems = ARRAY_SIZE(c66_mems),
> @@ -751,8 +759,16 @@ static const struct k3_dsp_dev_data c66_data = {
> .uses_lreset = true,
> };
>
> +static const struct k3_dsp_dev_data c71_data = {
> + .mems = c71_mems,
> + .num_mems = ARRAY_SIZE(c71_mems),
> + .boot_align_addr = SZ_2M,
> + .uses_lreset = false,
Right
> +};
> +
> static const struct of_device_id k3_dsp_of_match[] = {
> { .compatible = "ti,j721e-c66-dsp", .data = &c66_data, },
> + { .compatible = "ti,j721e-c71-dsp", .data = &c71_data, },
> { /* sentinel */ },
> };
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> MODULE_DEVICE_TABLE(of, k3_dsp_of_match);
> --
> 2.26.0
>
^ permalink raw reply
* Re: [PATCH v5 00/11] mediatek: add support for MediaTek Ethernet MAC
From: David Miller @ 2020-05-22 21:36 UTC (permalink / raw)
To: matthias.bgg
Cc: brgl, robh+dt, john, sean.wang, Mark-MC.Lee, kuba, arnd, fparent,
hkallweit1, edwin.peer, devicetree, linux-kernel, netdev,
linux-arm-kernel, linux-mediatek, stephane.leprovost, pedro.tsai,
andrew.perepech, bgolaszewski
In-Reply-To: <1f941213-7ca2-c138-3530-85c34ebf0d53@gmail.com>
From: Matthias Brugger <matthias.bgg@gmail.com>
Date: Fri, 22 May 2020 23:31:50 +0200
>
>
> On 22/05/2020 23:20, David Miller wrote:
>> From: Bartosz Golaszewski <brgl@bgdev.pl>
>> Date: Fri, 22 May 2020 14:06:49 +0200
>>
>>> This series adds support for the STAR Ethernet Controller present on MediaTeK
>>> SoCs from the MT8* family.
>>
>> Series applied to net-next, thank you.
>>
>
> If you say "series applied" do you mean you also applied the device tree parts?
> These should go through my branch, because there could be conflicts if there are
> other device tree patches from other series, not related with network, touching
> the same files.
It's starting to get rediculous and tedious to manage the DT changes
when they are tied to new networking drivers and such.
And in any event, it is the patch series submitter's responsibility to
sort these issues out, separate the patches based upon target tree, and
clearly indicate this in the introductory posting and Subject lines.
^ 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