* Re: [PATCH net 1/4] net: ethernet: fec: move GPR register offset and bit into DT
From: Fuzzey, Martin @ 2020-05-23 9:55 UTC (permalink / raw)
To: Andy Duan; +Cc: David S. Miller, netdev, Rob Herring, Shawn Guo, devicetree
In-Reply-To: <1589963516-26703-2-git-send-email-fugang.duan@nxp.com>
Hi Andy,
> Fixes: da722186f654(net: fec: set GPR bit on suspend by DT configuration)
Just a nitpick maybe but I don't really think this need as Fixes: tag.
That commit didn't actually *break* anything AFAIK.
It added WoL support for *some* SoCs that didn't have any in mainline
and didn't hurt the others.
Of course it turned out to be insufficient for the multiple FEC case
so this patch series is a welcome improvement.
> struct fec_devinfo {
> u32 quirks;
> - u8 stop_gpr_reg;
> - u8 stop_gpr_bit;
> };
This structure has become redundant now that it only contains a single
u32 quirks field.
So we *could* go back to storing the quirks bitmask directly in
.driver_data as was done before.
It's a slight wastage to keep the, now unnecessary, indirection,
though the size impact is small
and it's only used at probe() time not on a hot path.
But switching back could be seen as code churn too...
I don't have a strong opinion on this, so just noting it to see what
others think.
Martin
^ permalink raw reply
* Re: [PATCH net 2/4] dt-bindings: fec: update the gpr property
From: Fuzzey, Martin @ 2020-05-23 10:15 UTC (permalink / raw)
To: Andy Duan; +Cc: David S. Miller, netdev, Rob Herring, Shawn Guo, devicetree
In-Reply-To: <1589963516-26703-3-git-send-email-fugang.duan@nxp.com>
> - gpr: phandle of SoC general purpose register mode. Required for wake on LAN
> - on some SoCs
> + on some SoCs. Register bits of stop mode control, the format is
> + <&gpr req_gpr req_bit>.
> + gpr is the phandle to general purpose register node.
> + req_gpr is the gpr register offset for ENET stop request.
> + req_bit is the gpr bit offset for ENET stop request.
>
More of a DT binding changes policy question, do we care about
supporting the old
no argument binding too?
I don't think it actually matters seeing as the no argument gpr node
binding was only added recently anyway.
But it was backported to the stable trees and
Documentation/bindings/ABI.txt says
"Bindings can be augmented, but the driver shouldn't break when given
the old binding. ie. add additional properties, but don't change the
meaning of an existing property. For drivers, default to the original
behaviour when a newly added property is missing."
Myself I think this is overkill in this case and am fine with just
changing the binding without the driver handling the old case but
that's Rob's call to make I think.
Martin
^ permalink raw reply
* Re: [PATCH 3/4] dt-bindings: i2c-stm32: add SMBus Alert bindings
From: wsa @ 2020-05-23 10:36 UTC (permalink / raw)
To: Rob Herring, mark.rutland@arm.com, Pierre Yves MORDRET,
mcoquelin.stm32@gmail.com, Alexandre TORGUE,
linux-i2c@vger.kernel.org, devicetree@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Fabrice GASNIER
In-Reply-To: <20200513054231.GA16558@gnbcxd0016.gnb.st.com>
[-- Attachment #1: Type: text/plain, Size: 1309 bytes --]
> > > + st,smbus-alert:
> > > + description: Enable the SMBus Alert feature
> > > + $ref: /schemas/types.yaml#/definitions/flag
> > > +
> >
> > We already have smbus_alert interrupt. Can't you just check for this in
> > the slave nodes and enable if found?
>
> My understanding reading the code (smbalert_probe within i2c-smbus.c, of_i2c_setup_smbus_alert called when
> registering an adapter within i2c-core-smbus.c) is that smbus_alert refers to an interrupt on the
> adapter side. That is an interrupt that would be triggered when the adapter is receiving an smbus_alert
> message.
> In our case (stm32f7), we do not have specific interrupt for that purpose. The interrupt triggered when
> an SMBUS Alert is received (by the adapter) is the same interrupt as for other reasons and we check
> within the irq handler within stm32f7 the reason before calling i2c_handle_smbus_alert if the status
> register indicated an SMBUS Alert.
> So my understanding is that we cannot rely on the mechanism of naming an interrupt smbus_alert.
> Did I misunderstood something ?
I just wonder what is bad about specifying the same interrupt twice in
the interrupt properties? You could then check in probe if "smbus_alert"
is populated and if it matches the main irq.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 1/4] i2c: smbus: add core function handling SMBus host-notify
From: Wolfram Sang @ 2020-05-23 10:46 UTC (permalink / raw)
To: Alain Volmat, Benjamin Tissoires
Cc: robh+dt, mark.rutland, pierre-yves.mordret, mcoquelin.stm32,
alexandre.torgue, linux-i2c, devicetree, linux-stm32,
linux-arm-kernel, linux-kernel, fabrice.gasnier
In-Reply-To: <1588657871-14747-2-git-send-email-alain.volmat@st.com>
[-- Attachment #1: Type: text/plain, Size: 2278 bytes --]
Adding Benjamin who mainly implemented this.
On Tue, May 05, 2020 at 07:51:08AM +0200, Alain Volmat wrote:
> SMBus Host-Notify protocol, from the adapter point of view
> consist of receiving a message from a client, including the
> client address and some other data.
>
> It can be simply handled by creating a new slave device
> and registering a callback performing the parsing of the
> message received from the client.
>
> This commit introduces two new core functions
> * i2c_new_smbus_host_notify_device
> * i2c_free_smbus_host_notify_device
> that take care of registration of the new slave device and
> callback and will call i2c_handle_smbus_host_notify once a
> Host-Notify event is received.
Yay, cool idea to use the slave interface. I like it a lot!
> +static int i2c_smbus_host_notify_cb(struct i2c_client *client,
> + enum i2c_slave_event event, u8 *val)
> +{
> + struct i2c_smbus_host_notify_status *status = client->dev.platform_data;
> + int ret;
> +
> + switch (event) {
> + case I2C_SLAVE_WRITE_REQUESTED:
> + status->notify_start = true;
> + break;
> + case I2C_SLAVE_WRITE_RECEIVED:
> + /* We only retrieve the first byte received (addr)
> + * since there is currently no way to retrieve the data
> + * parameter from the client.
Maybe s/no way/no support/ ? I still wonder if we couldn't add it
somehow. Once we find a device which needs this, of course.
> + */
> + if (!status->notify_start)
> + break;
> + status->addr = *val;
> + status->notify_start = false;
> + break;
> + case I2C_SLAVE_STOP:
What about setting 'notify_start' to false here as well? In the case of
an incomplete write?
> + ret = i2c_handle_smbus_host_notify(client->adapter,
> + status->addr);
> + if (ret < 0) {
> + dev_warn(&client->adapter->dev, "failed to handle host_notify (%d)\n",
> + ret);
I think we should rather add such error strings to the core if we think
they are needed. I am not convinced they are, though.
> + return ret;
> + }
> + break;
> + default:
> + /* Only handle necessary events */
> + break;
> + }
> +
> + return 0;
> +}
> +
Rest of the code looks good. Maybe we should compile all this only when
I2C_SLAVE is enabled?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 2/4] i2c: addition of client reg/unreg callbacks
From: Wolfram Sang @ 2020-05-23 10:49 UTC (permalink / raw)
To: Alain Volmat
Cc: robh+dt, mark.rutland, pierre-yves.mordret, mcoquelin.stm32,
alexandre.torgue, linux-i2c, devicetree, linux-stm32,
linux-arm-kernel, linux-kernel, fabrice.gasnier
In-Reply-To: <1588657871-14747-3-git-send-email-alain.volmat@st.com>
[-- Attachment #1: Type: text/plain, Size: 540 bytes --]
On Tue, May 05, 2020 at 07:51:09AM +0200, Alain Volmat wrote:
> Addition of two callbacks reg_client and unreg_client that can be
> implemented by adapter drivers in order to take action whenever a
> client is being registered to it.
>
> Signed-off-by: Alain Volmat <alain.volmat@st.com>
Sorry, but NACK. After years of work, we just recently got rid of attach
and detach callbacks. They were abused in quite a lot of ways. I think
we can find other solutions to what you need them for. Let's move the
discussion to patch 4.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 4/4] i2c: stm32f7: Add SMBus-specific protocols support
From: Wolfram Sang @ 2020-05-23 11:01 UTC (permalink / raw)
To: Alain Volmat, Benjamin Tissoires
Cc: robh+dt, mark.rutland, pierre-yves.mordret, mcoquelin.stm32,
alexandre.torgue, linux-i2c, devicetree, linux-stm32,
linux-arm-kernel, linux-kernel, fabrice.gasnier
In-Reply-To: <1588657871-14747-5-git-send-email-alain.volmat@st.com>
[-- Attachment #1: Type: text/plain, Size: 980 bytes --]
> +static int stm32f7_i2c_reg_client(struct i2c_client *client)
> +{
> + struct stm32f7_i2c_dev *i2c_dev = i2c_get_adapdata(client->adapter);
> + int ret;
> +
> + if (client->flags & I2C_CLIENT_HOST_NOTIFY) {
> + /* Only enable on the first device registration */
> + if (atomic_inc_return(&i2c_dev->host_notify_cnt) == 1) {
> + ret = stm32f7_i2c_enable_smbus_host(i2c_dev);
> + if (ret) {
> + dev_err(i2c_dev->dev,
> + "failed to enable SMBus host notify (%d)\n",
> + ret);
> + return ret;
> + }
> + }
> + }
> +
> + return 0;
> +}
So, as mentioned in the other review, I'd like to evaluate other
possibilities for the above:
- One option is to enable it globally in probe(). Then you lose the
possibility to have a device at address 0x08.
- Enable it in probe() only if there is a generic binding "host-notify".
- Let the core scan for a device with HOST_NOTIFY when registering an
adapter and then call back into the driver somehow?
Other ideas?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v4 1/6] printk: Collapse shutdown types into a single dump reason
From: Michael Ellerman @ 2020-05-23 11:16 UTC (permalink / raw)
To: Kees Cook, Pavel Tatashin
Cc: Kees Cook, Petr Mladek, Anton Vorontsov, Colin Cross, Tony Luck,
Jonathan Corbet, Benson Leung, Rob Herring,
Benjamin Herrenschmidt, Paul Mackerras, Enric Balletbo i Serra,
Sergey Senozhatsky, Steven Rostedt, linux-doc, linux-kernel,
devicetree, linuxppc-dev
In-Reply-To: <20200515184434.8470-2-keescook@chromium.org>
Kees Cook <keescook@chromium.org> writes:
> To turn the KMSG_DUMP_* reasons into a more ordered list, collapse
> the redundant KMSG_DUMP_(RESTART|HALT|POWEROFF) reasons into
> KMSG_DUMP_SHUTDOWN. The current users already don't meaningfully
> distinguish between them, so there's no need to, as discussed here:
> https://lore.kernel.org/lkml/CA+CK2bAPv5u1ih5y9t5FUnTyximtFCtDYXJCpuyjOyHNOkRdqw@mail.gmail.com/
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> arch/powerpc/kernel/nvram_64.c | 4 +---
> fs/pstore/platform.c | 8 ++------
> include/linux/kmsg_dump.h | 4 +---
> kernel/reboot.c | 6 +++---
> 4 files changed, 7 insertions(+), 15 deletions(-)
>
> diff --git a/arch/powerpc/kernel/nvram_64.c b/arch/powerpc/kernel/nvram_64.c
> index fb4f61096613..0cd1c88bfc8b 100644
> --- a/arch/powerpc/kernel/nvram_64.c
> +++ b/arch/powerpc/kernel/nvram_64.c
> @@ -655,9 +655,7 @@ static void oops_to_nvram(struct kmsg_dumper *dumper,
> int rc = -1;
>
> switch (reason) {
> - case KMSG_DUMP_RESTART:
> - case KMSG_DUMP_HALT:
> - case KMSG_DUMP_POWEROFF:
> + case KMSG_DUMP_SHUTDOWN:
> /* These are almost always orderly shutdowns. */
> return;
> case KMSG_DUMP_OOPS:
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
cheers
^ permalink raw reply
* Re: [PATCH v11 2/6] mfd: mp2629: Add support for mps battery charger
From: saravanan sekar @ 2020-05-23 12:20 UTC (permalink / raw)
To: Lee Jones
Cc: andy.shevchenko, robh+dt, jic23, knaack.h, lars, pmeerw, sre,
devicetree, linux-kernel, linux-iio, linux-pm
In-Reply-To: <20200519103741.GW271301@dell>
Hi Lee,
On 19/05/20 12:37 pm, Lee Jones wrote:
> On Thu, 30 Apr 2020, Saravanan Sekar wrote:
>
>> mp2629 is a highly-integrated switching-mode battery charge management
>> device for single-cell Li-ion or Li-polymer battery.
>>
>> Add MFD core enables chip access for ADC driver for battery readings,
>> and a power supply battery-charger driver
>>
>> Signed-off-by: Saravanan Sekar <sravanhome@gmail.com>
>> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
>> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>> ---
>> drivers/mfd/Kconfig | 9 +++++
>> drivers/mfd/Makefile | 2 +
>> drivers/mfd/mp2629.c | 79 ++++++++++++++++++++++++++++++++++++++
>> include/linux/mfd/mp2629.h | 17 ++++++++
>> 4 files changed, 107 insertions(+)
>> create mode 100644 drivers/mfd/mp2629.c
>> create mode 100644 include/linux/mfd/mp2629.h
> For my own reference (apply this as-is to your sign-off block):
>
> Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
>
Do I have to resend with above sign-off in all the patch?
Thanks,
Saravanan
^ permalink raw reply
* Re: [PATCH v3 0/6] sc16is7xx: IrDA mode and threaded IRQs
From: Daniel Mack @ 2020-05-23 12:27 UTC (permalink / raw)
To: Greg KH
Cc: devicetree, linux-serial, robh+dt, jslaby, jringle, m.brock,
pascal.huerst
In-Reply-To: <20200522090755.GA1189521@kroah.com>
On 5/22/20 11:07 AM, Greg KH wrote:
> On Thu, May 21, 2020 at 11:11:46AM +0200, Daniel Mack wrote:
>> This is v3 of the series.
>>
>> v3:
>>
>> * Add my s-o-b to the first two patches
>>
>> v2:
>>
>> * Change single bool properties into an array
>> (suggested by Rob Herring)
>> * Add a patch first try TRIGGER_LOW and SHARED interrupts, and then
>> fall back to FALLING edge if the IRQ controller fails to provide the
>> former (suggested by Maarten Brock)
>> * Add a patch to check for the device presence
>>
>> Daniel Mack (4):
>> sc16is7xx: Always use falling edge IRQ
>> sc16is7xx: Use threaded IRQ
>> sc16is7xx: Allow sharing the IRQ line
>> sc16is7xx: Read the LSR register for basic device presence check
>>
>> Pascal Huerst (2):
>> dt-bindings: sc16is7xx: Add flag to activate IrDA mode
>> sc16is7xx: Add flag to activate IrDA mode
>
> As I have to wait for the DT addition to be reviewed before applying the
> first 2 patches here, I've taken the other 4 instead at the moment. If
> you could rebase the first two and resend when they get acked, so that I
> could apply them, that would be great.
Sure, will do. Thanks :)
Daniel
^ permalink raw reply
* [PATCH] arm64: dts: qcom: sm8250: use dt-bindings defines for clocks
From: Jonathan Marek @ 2020-05-23 13:12 UTC (permalink / raw)
To: linux-arm-msm
Cc: Andy Gross, Bjorn Andersson, Rob Herring,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
Use the dt-bindings defines for qupv3_id_1 node's clocks.
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index 9c210fbac65e..04c9c215ffcd 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -292,7 +292,8 @@ qupv3_id_1: geniqup@ac0000 {
compatible = "qcom,geni-se-qup";
reg = <0x0 0x00ac0000 0x0 0x6000>;
clock-names = "m-ahb", "s-ahb";
- clocks = <&gcc 133>, <&gcc 134>;
+ clocks = <&gcc GCC_QUPV3_WRAP_1_M_AHB_CLK>,
+ <&gcc GCC_QUPV3_WRAP_1_S_AHB_CLK>;
#address-cells = <2>;
#size-cells = <2>;
ranges;
@@ -302,7 +303,7 @@ uart2: serial@a90000 {
compatible = "qcom,geni-debug-uart";
reg = <0x0 0x00a90000 0x0 0x4000>;
clock-names = "se";
- clocks = <&gcc 113>;
+ clocks = <&gcc GCC_QUPV3_WRAP1_S4_CLK>;
interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
status = "disabled";
};
--
2.26.1
^ permalink raw reply related
* Re: [PATCH v5 00/11] mediatek: add support for MediaTek Ethernet MAC
From: Matthias Brugger @ 2020-05-23 13:14 UTC (permalink / raw)
To: David Miller
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: <20200522.143656.1986528672037093503.davem@davemloft.net>
On 5/22/20 11:36 PM, David Miller wrote:
> 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.
>
My experience in with other subsystems is that the DTS changes which
enables de device are part of the series.
They are normally prefixed with "arm64: dts:" or "ARM: dts:" for 32 bit
SoCs. That also normally the way I detect patches which should through
my tree.
Anyway I'll try to remember submitters in the future to send DTS patches
for network devices as separate series. That makes my life a bit more
complicated as I afterwards have to find the related DTS series to the
driver you accepted, but I'll try.
Regards,
Matthias
^ permalink raw reply
* Re: [PATCH 0/5] net: provide a devres variant of register_netdev()
From: Bartosz Golaszewski @ 2020-05-23 13:14 UTC (permalink / raw)
To: David Miller
Cc: Jonathan Corbet, Matthias Brugger, John Crispin, Sean Wang,
Mark Lee, Jakub Kicinski, Arnd Bergmann, Fabien Parent,
Heiner Kallweit, Edwin Peer, devicetree,
Linux Kernel Mailing List, netdev, Linux ARM,
moderated list:ARM/Mediatek SoC..., Stephane Le Provost,
Pedro Tsai, Andrew Perepech, Bartosz Golaszewski
In-Reply-To: <20200522.153653.998395486877096103.davem@davemloft.net>
sob., 23 maj 2020 o 00:36 David Miller <davem@davemloft.net> napisał(a):
>
> From: Bartosz Golaszewski <brgl@bgdev.pl>
> Date: Wed, 20 May 2020 13:44:10 +0200
>
> > net: ethernet: mtk_eth_mac: use devm_register_netdev()
>
> This patch doesn't apply to net-next.
>
> Neither the source file drivers/net/ethernet/mediatek/mtk_eth_mac.c,
> nor the function mtk_mac_probe() even exist in the net-next GIT
> tree.
Indeed. The driver got renamed in v5. I didn't resend a new version of
this series because I thought there would be a discussion about its
usefulness. I'll send a rebased version then.
Bartosz
^ permalink raw reply
* [PATCH] arm64: dts: qcom: sm8250: rename spmi node to spmi_bus
From: Jonathan Marek @ 2020-05-23 13:21 UTC (permalink / raw)
To: linux-arm-msm
Cc: Andy Gross, Bjorn Andersson, Rob Herring,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
The pm8150 dtsi files refer to it as spmi_bus, so change it.
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index 04c9c215ffcd..a273b99bf1e6 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -578,7 +578,7 @@ pdc: interrupt-controller@b220000 {
interrupt-controller;
};
- spmi: qcom,spmi@c440000 {
+ spmi_bus: qcom,spmi@c440000 {
compatible = "qcom,spmi-pmic-arb";
reg = <0x0 0x0c440000 0x0 0x0001100>,
<0x0 0x0c600000 0x0 0x2000000>,
--
2.26.1
^ permalink raw reply related
* [PATCH] arm64: dts: qcom: sm8250: sort nodes by physical address
From: Jonathan Marek @ 2020-05-23 13:22 UTC (permalink / raw)
To: linux-arm-msm
Cc: Andy Gross, Bjorn Andersson, Rob Herring,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
Other dts have nodes sorted by physical address, be consistent with that.
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 176 +++++++++++++--------------
1 file changed, 88 insertions(+), 88 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index a273b99bf1e6..bc8a14df60e5 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -379,6 +379,12 @@ ufs_mem_phy_lanes: lanes@1d87400 {
};
};
+ tcsr_mutex: hwlock@1f40000 {
+ compatible = "qcom,tcsr-mutex";
+ reg = <0x0 0x01f40000 0x0 0x40000>;
+ #hwlock-cells = <1>;
+ };
+
usb_1_hsphy: phy@88e3000 {
compatible = "qcom,sm8250-usb-hs-phy",
"qcom,usb-snps-hs-7nm-phy";
@@ -559,15 +565,6 @@ usb_2_dwc3: dwc3@a800000 {
};
};
- intc: interrupt-controller@17a00000 {
- compatible = "arm,gic-v3";
- #interrupt-cells = <3>;
- interrupt-controller;
- reg = <0x0 0x17a00000 0x0 0x10000>, /* GICD */
- <0x0 0x17a60000 0x0 0x100000>; /* GICR * 8 */
- interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
- };
-
pdc: interrupt-controller@b220000 {
compatible = "qcom,sm8250-pdc", "qcom,pdc";
reg = <0 0x0b220000 0 0x30000>, <0 0x17c000f0 0 0x60>;
@@ -596,85 +593,6 @@ spmi_bus: qcom,spmi@c440000 {
#interrupt-cells = <4>;
};
- apps_rsc: rsc@18200000 {
- label = "apps_rsc";
- compatible = "qcom,rpmh-rsc";
- reg = <0x0 0x18200000 0x0 0x10000>,
- <0x0 0x18210000 0x0 0x10000>,
- <0x0 0x18220000 0x0 0x10000>;
- reg-names = "drv-0", "drv-1", "drv-2";
- interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
- qcom,tcs-offset = <0xd00>;
- qcom,drv-id = <2>;
- qcom,tcs-config = <ACTIVE_TCS 2>, <SLEEP_TCS 3>,
- <WAKE_TCS 3>, <CONTROL_TCS 1>;
-
- rpmhcc: clock-controller {
- compatible = "qcom,sm8250-rpmh-clk";
- #clock-cells = <1>;
- clock-names = "xo";
- clocks = <&xo_board>;
- };
-
- rpmhpd: power-controller {
- compatible = "qcom,sm8250-rpmhpd";
- #power-domain-cells = <1>;
- operating-points-v2 = <&rpmhpd_opp_table>;
-
- rpmhpd_opp_table: opp-table {
- compatible = "operating-points-v2";
-
- rpmhpd_opp_ret: opp1 {
- opp-level = <RPMH_REGULATOR_LEVEL_RETENTION>;
- };
-
- rpmhpd_opp_min_svs: opp2 {
- opp-level = <RPMH_REGULATOR_LEVEL_MIN_SVS>;
- };
-
- rpmhpd_opp_low_svs: opp3 {
- opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
- };
-
- rpmhpd_opp_svs: opp4 {
- opp-level = <RPMH_REGULATOR_LEVEL_SVS>;
- };
-
- rpmhpd_opp_svs_l1: opp5 {
- opp-level = <RPMH_REGULATOR_LEVEL_SVS_L1>;
- };
-
- rpmhpd_opp_nom: opp6 {
- opp-level = <RPMH_REGULATOR_LEVEL_NOM>;
- };
-
- rpmhpd_opp_nom_l1: opp7 {
- opp-level = <RPMH_REGULATOR_LEVEL_NOM_L1>;
- };
-
- rpmhpd_opp_nom_l2: opp8 {
- opp-level = <RPMH_REGULATOR_LEVEL_NOM_L2>;
- };
-
- rpmhpd_opp_turbo: opp9 {
- opp-level = <RPMH_REGULATOR_LEVEL_TURBO>;
- };
-
- rpmhpd_opp_turbo_l1: opp10 {
- opp-level = <RPMH_REGULATOR_LEVEL_TURBO_L1>;
- };
- };
- };
- };
-
- tcsr_mutex: hwlock@1f40000 {
- compatible = "qcom,tcsr-mutex";
- reg = <0x0 0x01f40000 0x0 0x40000>;
- #hwlock-cells = <1>;
- };
-
tlmm: pinctrl@f100000 {
compatible = "qcom,sm8250-pinctrl";
reg = <0 0x0f100000 0 0x300000>,
@@ -690,6 +608,15 @@ tlmm: pinctrl@f100000 {
wakeup-parent = <&pdc>;
};
+ intc: interrupt-controller@17a00000 {
+ compatible = "arm,gic-v3";
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ reg = <0x0 0x17a00000 0x0 0x10000>, /* GICD */
+ <0x0 0x17a60000 0x0 0x100000>; /* GICR * 8 */
+ interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
timer@17c20000 {
#address-cells = <2>;
#size-cells = <2>;
@@ -749,6 +676,79 @@ frame@17c2d000 {
};
};
+ apps_rsc: rsc@18200000 {
+ label = "apps_rsc";
+ compatible = "qcom,rpmh-rsc";
+ reg = <0x0 0x18200000 0x0 0x10000>,
+ <0x0 0x18210000 0x0 0x10000>,
+ <0x0 0x18220000 0x0 0x10000>;
+ reg-names = "drv-0", "drv-1", "drv-2";
+ interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
+ qcom,tcs-offset = <0xd00>;
+ qcom,drv-id = <2>;
+ qcom,tcs-config = <ACTIVE_TCS 2>, <SLEEP_TCS 3>,
+ <WAKE_TCS 3>, <CONTROL_TCS 1>;
+
+ rpmhcc: clock-controller {
+ compatible = "qcom,sm8250-rpmh-clk";
+ #clock-cells = <1>;
+ clock-names = "xo";
+ clocks = <&xo_board>;
+ };
+
+ rpmhpd: power-controller {
+ compatible = "qcom,sm8250-rpmhpd";
+ #power-domain-cells = <1>;
+ operating-points-v2 = <&rpmhpd_opp_table>;
+
+ rpmhpd_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ rpmhpd_opp_ret: opp1 {
+ opp-level = <RPMH_REGULATOR_LEVEL_RETENTION>;
+ };
+
+ rpmhpd_opp_min_svs: opp2 {
+ opp-level = <RPMH_REGULATOR_LEVEL_MIN_SVS>;
+ };
+
+ rpmhpd_opp_low_svs: opp3 {
+ opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
+ };
+
+ rpmhpd_opp_svs: opp4 {
+ opp-level = <RPMH_REGULATOR_LEVEL_SVS>;
+ };
+
+ rpmhpd_opp_svs_l1: opp5 {
+ opp-level = <RPMH_REGULATOR_LEVEL_SVS_L1>;
+ };
+
+ rpmhpd_opp_nom: opp6 {
+ opp-level = <RPMH_REGULATOR_LEVEL_NOM>;
+ };
+
+ rpmhpd_opp_nom_l1: opp7 {
+ opp-level = <RPMH_REGULATOR_LEVEL_NOM_L1>;
+ };
+
+ rpmhpd_opp_nom_l2: opp8 {
+ opp-level = <RPMH_REGULATOR_LEVEL_NOM_L2>;
+ };
+
+ rpmhpd_opp_turbo: opp9 {
+ opp-level = <RPMH_REGULATOR_LEVEL_TURBO>;
+ };
+
+ rpmhpd_opp_turbo_l1: opp10 {
+ opp-level = <RPMH_REGULATOR_LEVEL_TURBO_L1>;
+ };
+ };
+ };
+ };
+
cpufreq_hw: cpufreq@18591000 {
compatible = "qcom,cpufreq-hw";
reg = <0 0x18591000 0 0x1000>,
--
2.26.1
^ permalink raw reply related
* [PATCH v2 0/5] net: provide a devres variant of register_netdev()
From: Bartosz Golaszewski @ 2020-05-23 13:27 UTC (permalink / raw)
To: Jonathan Corbet, David S . Miller, Matthias Brugger, John Crispin,
Sean Wang, Mark Lee, Jakub Kicinski, Arnd Bergmann, Fabien Parent,
Heiner Kallweit, Edwin Peer
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel,
linux-mediatek, Stephane Le Provost, Pedro Tsai, Andrew Perepech,
Bartosz Golaszewski
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Using devres helpers allows to shrink the probing code, avoid memory leaks in
error paths make sure the order in which resources are freed is the exact
opposite of their allocation. This series proposes to add a devres variant
of register_netdev() that will only work with net_device structures whose
memory is also managed.
First we add the missing documentation entry for the only other networking
devres helper: devm_alloc_etherdev().
Next we move devm_alloc_etherdev() into a separate source file.
We then use a proxy structure in devm_alloc_etherdev() to improve readability.
Last: we implement devm_register_netdev() and use it in mtk-eth-mac driver.
v1 -> v2:
- rebase on top of net-next after driver rename, no functional changes
Bartosz Golaszewski (5):
Documentation: devres: add a missing section for networking helpers
net: move devres helpers into a separate source file
net: devres: define a separate devres structure for
devm_alloc_etherdev()
net: devres: provide devm_register_netdev()
net: ethernet: mtk_star_emac: use devm_register_netdev()
.../driver-api/driver-model/devres.rst | 5 +
drivers/net/ethernet/mediatek/mtk_star_emac.c | 17 +---
include/linux/netdevice.h | 2 +
net/Makefile | 2 +-
net/devres.c | 95 +++++++++++++++++++
net/ethernet/eth.c | 28 ------
6 files changed, 104 insertions(+), 45 deletions(-)
create mode 100644 net/devres.c
--
2.25.0
^ permalink raw reply
* [PATCH v2 1/5] Documentation: devres: add a missing section for networking helpers
From: Bartosz Golaszewski @ 2020-05-23 13:27 UTC (permalink / raw)
To: Jonathan Corbet, David S . Miller, Matthias Brugger, John Crispin,
Sean Wang, Mark Lee, Jakub Kicinski, Arnd Bergmann, Fabien Parent,
Heiner Kallweit, Edwin Peer
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel,
linux-mediatek, Stephane Le Provost, Pedro Tsai, Andrew Perepech,
Bartosz Golaszewski
In-Reply-To: <20200523132711.30617-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Add a new section for networking devres helpers to devres.rst and list
the two existing devm functions.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
Documentation/driver-api/driver-model/devres.rst | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst
index 46c13780994c..50df28d20fa7 100644
--- a/Documentation/driver-api/driver-model/devres.rst
+++ b/Documentation/driver-api/driver-model/devres.rst
@@ -372,6 +372,10 @@ MUX
devm_mux_chip_register()
devm_mux_control_get()
+NET
+ devm_alloc_etherdev()
+ devm_alloc_etherdev_mqs()
+
PER-CPU MEM
devm_alloc_percpu()
devm_free_percpu()
--
2.25.0
^ permalink raw reply related
* [PATCH v2 3/5] net: devres: define a separate devres structure for devm_alloc_etherdev()
From: Bartosz Golaszewski @ 2020-05-23 13:27 UTC (permalink / raw)
To: Jonathan Corbet, David S . Miller, Matthias Brugger, John Crispin,
Sean Wang, Mark Lee, Jakub Kicinski, Arnd Bergmann, Fabien Parent,
Heiner Kallweit, Edwin Peer
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel,
linux-mediatek, Stephane Le Provost, Pedro Tsai, Andrew Perepech,
Bartosz Golaszewski
In-Reply-To: <20200523132711.30617-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Not using a proxy structure to store struct net_device doesn't save
anything in terms of compiled code size or memory usage but significantly
decreases the readability of the code with all the pointer casting.
Define struct net_device_devres and use it in devm_alloc_etherdev_mqs().
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
net/devres.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/net/devres.c b/net/devres.c
index c1465d9f9019..b97b0c5a8216 100644
--- a/net/devres.c
+++ b/net/devres.c
@@ -7,30 +7,34 @@
#include <linux/etherdevice.h>
#include <linux/netdevice.h>
-static void devm_free_netdev(struct device *dev, void *res)
+struct net_device_devres {
+ struct net_device *ndev;
+};
+
+static void devm_free_netdev(struct device *dev, void *this)
{
- free_netdev(*(struct net_device **)res);
+ struct net_device_devres *res = this;
+
+ free_netdev(res->ndev);
}
struct net_device *devm_alloc_etherdev_mqs(struct device *dev, int sizeof_priv,
unsigned int txqs, unsigned int rxqs)
{
- struct net_device **dr;
- struct net_device *netdev;
+ struct net_device_devres *dr;
dr = devres_alloc(devm_free_netdev, sizeof(*dr), GFP_KERNEL);
if (!dr)
return NULL;
- netdev = alloc_etherdev_mqs(sizeof_priv, txqs, rxqs);
- if (!netdev) {
+ dr->ndev = alloc_etherdev_mqs(sizeof_priv, txqs, rxqs);
+ if (!dr->ndev) {
devres_free(dr);
return NULL;
}
- *dr = netdev;
devres_add(dev, dr);
- return netdev;
+ return dr->ndev;
}
EXPORT_SYMBOL(devm_alloc_etherdev_mqs);
--
2.25.0
^ permalink raw reply related
* [PATCH v2 4/5] net: devres: provide devm_register_netdev()
From: Bartosz Golaszewski @ 2020-05-23 13:27 UTC (permalink / raw)
To: Jonathan Corbet, David S . Miller, Matthias Brugger, John Crispin,
Sean Wang, Mark Lee, Jakub Kicinski, Arnd Bergmann, Fabien Parent,
Heiner Kallweit, Edwin Peer
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel,
linux-mediatek, Stephane Le Provost, Pedro Tsai, Andrew Perepech,
Bartosz Golaszewski
In-Reply-To: <20200523132711.30617-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Provide devm_register_netdev() - a device resource managed variant
of register_netdev(). This new helper will only work for net_device
structs that are also already managed by devres.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
.../driver-api/driver-model/devres.rst | 1 +
include/linux/netdevice.h | 2 +
net/devres.c | 55 +++++++++++++++++++
3 files changed, 58 insertions(+)
diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst
index 50df28d20fa7..fc242ed4bde5 100644
--- a/Documentation/driver-api/driver-model/devres.rst
+++ b/Documentation/driver-api/driver-model/devres.rst
@@ -375,6 +375,7 @@ MUX
NET
devm_alloc_etherdev()
devm_alloc_etherdev_mqs()
+ devm_register_netdev()
PER-CPU MEM
devm_alloc_percpu()
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index a18f8fdf4260..1a96e9c4ec36 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -4280,6 +4280,8 @@ struct net_device *alloc_netdev_mqs(int sizeof_priv, const char *name,
int register_netdev(struct net_device *dev);
void unregister_netdev(struct net_device *dev);
+int devm_register_netdev(struct device *dev, struct net_device *ndev);
+
/* General hardware address lists handling functions */
int __hw_addr_sync(struct netdev_hw_addr_list *to_list,
struct netdev_hw_addr_list *from_list, int addr_len);
diff --git a/net/devres.c b/net/devres.c
index b97b0c5a8216..57a6a88d11f6 100644
--- a/net/devres.c
+++ b/net/devres.c
@@ -38,3 +38,58 @@ struct net_device *devm_alloc_etherdev_mqs(struct device *dev, int sizeof_priv,
return dr->ndev;
}
EXPORT_SYMBOL(devm_alloc_etherdev_mqs);
+
+static void devm_netdev_release(struct device *dev, void *this)
+{
+ struct net_device_devres *res = this;
+
+ unregister_netdev(res->ndev);
+}
+
+static int netdev_devres_match(struct device *dev, void *this, void *match_data)
+{
+ struct net_device_devres *res = this;
+ struct net_device *ndev = match_data;
+
+ return ndev == res->ndev;
+}
+
+/**
+ * devm_register_netdev - resource managed variant of register_netdev()
+ * @dev: managing device for this netdev - usually the parent device
+ * @ndev: device to register
+ *
+ * This is a devres variant of register_netdev() for which the unregister
+ * function will be call automatically when the managing device is
+ * detached. Note: the net_device used must also be resource managed by
+ * the same struct device.
+ */
+int devm_register_netdev(struct device *dev, struct net_device *ndev)
+{
+ struct net_device_devres *dr;
+ int ret;
+
+ /* struct net_device must itself be managed. For now a managed netdev
+ * can only be allocated by devm_alloc_etherdev_mqs() so the check is
+ * straightforward.
+ */
+ if (WARN_ON(!devres_find(dev, devm_free_netdev,
+ netdev_devres_match, ndev)))
+ return -EINVAL;
+
+ dr = devres_alloc(devm_netdev_release, sizeof(*dr), GFP_KERNEL);
+ if (!dr)
+ return -ENOMEM;
+
+ ret = register_netdev(ndev);
+ if (ret) {
+ devres_free(dr);
+ return ret;
+ }
+
+ dr->ndev = ndev;
+ devres_add(ndev->dev.parent, dr);
+
+ return 0;
+}
+EXPORT_SYMBOL(devm_register_netdev);
--
2.25.0
^ permalink raw reply related
* [PATCH v2 5/5] net: ethernet: mtk_star_emac: use devm_register_netdev()
From: Bartosz Golaszewski @ 2020-05-23 13:27 UTC (permalink / raw)
To: Jonathan Corbet, David S . Miller, Matthias Brugger, John Crispin,
Sean Wang, Mark Lee, Jakub Kicinski, Arnd Bergmann, Fabien Parent,
Heiner Kallweit, Edwin Peer
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel,
linux-mediatek, Stephane Le Provost, Pedro Tsai, Andrew Perepech,
Bartosz Golaszewski
In-Reply-To: <20200523132711.30617-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Use the new devres variant of register_netdev() in the mtk-star-emac
driver and shrink the code by a couple lines.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
drivers/net/ethernet/mediatek/mtk_star_emac.c | 17 +----------------
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_star_emac.c b/drivers/net/ethernet/mediatek/mtk_star_emac.c
index 789c77af501f..b74349cede28 100644
--- a/drivers/net/ethernet/mediatek/mtk_star_emac.c
+++ b/drivers/net/ethernet/mediatek/mtk_star_emac.c
@@ -1519,13 +1519,6 @@ static void mtk_star_mdiobus_unregister(void *data)
mdiobus_unregister(priv->mii);
}
-static void mtk_star_unregister_netdev(void *data)
-{
- struct net_device *ndev = data;
-
- unregister_netdev(ndev);
-}
-
static int mtk_star_probe(struct platform_device *pdev)
{
struct device_node *of_node;
@@ -1641,15 +1634,7 @@ static int mtk_star_probe(struct platform_device *pdev)
netif_napi_add(ndev, &priv->napi, mtk_star_poll, MTK_STAR_NAPI_WEIGHT);
- ret = register_netdev(ndev);
- if (ret)
- return ret;
-
- ret = devm_add_action_or_reset(dev, mtk_star_unregister_netdev, ndev);
- if (ret)
- return ret;
-
- return 0;
+ return devm_register_netdev(dev, ndev);
}
static const struct of_device_id mtk_star_of_match[] = {
--
2.25.0
^ permalink raw reply related
* [PATCH v2 2/5] net: move devres helpers into a separate source file
From: Bartosz Golaszewski @ 2020-05-23 13:27 UTC (permalink / raw)
To: Jonathan Corbet, David S . Miller, Matthias Brugger, John Crispin,
Sean Wang, Mark Lee, Jakub Kicinski, Arnd Bergmann, Fabien Parent,
Heiner Kallweit, Edwin Peer
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel,
linux-mediatek, Stephane Le Provost, Pedro Tsai, Andrew Perepech,
Bartosz Golaszewski
In-Reply-To: <20200523132711.30617-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
There's currently only a single devres helper in net/ - devm variant
of alloc_etherdev. Let's move it to net/devres.c with the intention of
assing a second one: devm_register_netdev(). This new routine will need
to know the address of the release function of devm_alloc_etherdev() so
that it can verify (using devres_find()) that the struct net_device
that's being passed to it is also resource managed.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
net/Makefile | 2 +-
net/devres.c | 36 ++++++++++++++++++++++++++++++++++++
net/ethernet/eth.c | 28 ----------------------------
3 files changed, 37 insertions(+), 29 deletions(-)
create mode 100644 net/devres.c
diff --git a/net/Makefile b/net/Makefile
index 07ea48160874..5744bf1997fd 100644
--- a/net/Makefile
+++ b/net/Makefile
@@ -6,7 +6,7 @@
# Rewritten to use lists instead of if-statements.
#
-obj-$(CONFIG_NET) := socket.o core/
+obj-$(CONFIG_NET) := devres.o socket.o core/
tmp-$(CONFIG_COMPAT) := compat.o
obj-$(CONFIG_NET) += $(tmp-y)
diff --git a/net/devres.c b/net/devres.c
new file mode 100644
index 000000000000..c1465d9f9019
--- /dev/null
+++ b/net/devres.c
@@ -0,0 +1,36 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * This file contains all networking devres helpers.
+ */
+
+#include <linux/device.h>
+#include <linux/etherdevice.h>
+#include <linux/netdevice.h>
+
+static void devm_free_netdev(struct device *dev, void *res)
+{
+ free_netdev(*(struct net_device **)res);
+}
+
+struct net_device *devm_alloc_etherdev_mqs(struct device *dev, int sizeof_priv,
+ unsigned int txqs, unsigned int rxqs)
+{
+ struct net_device **dr;
+ struct net_device *netdev;
+
+ dr = devres_alloc(devm_free_netdev, sizeof(*dr), GFP_KERNEL);
+ if (!dr)
+ return NULL;
+
+ netdev = alloc_etherdev_mqs(sizeof_priv, txqs, rxqs);
+ if (!netdev) {
+ devres_free(dr);
+ return NULL;
+ }
+
+ *dr = netdev;
+ devres_add(dev, dr);
+
+ return netdev;
+}
+EXPORT_SYMBOL(devm_alloc_etherdev_mqs);
diff --git a/net/ethernet/eth.c b/net/ethernet/eth.c
index c8b903302ff2..dac65180c4ef 100644
--- a/net/ethernet/eth.c
+++ b/net/ethernet/eth.c
@@ -400,34 +400,6 @@ struct net_device *alloc_etherdev_mqs(int sizeof_priv, unsigned int txqs,
}
EXPORT_SYMBOL(alloc_etherdev_mqs);
-static void devm_free_netdev(struct device *dev, void *res)
-{
- free_netdev(*(struct net_device **)res);
-}
-
-struct net_device *devm_alloc_etherdev_mqs(struct device *dev, int sizeof_priv,
- unsigned int txqs, unsigned int rxqs)
-{
- struct net_device **dr;
- struct net_device *netdev;
-
- dr = devres_alloc(devm_free_netdev, sizeof(*dr), GFP_KERNEL);
- if (!dr)
- return NULL;
-
- netdev = alloc_etherdev_mqs(sizeof_priv, txqs, rxqs);
- if (!netdev) {
- devres_free(dr);
- return NULL;
- }
-
- *dr = netdev;
- devres_add(dev, dr);
-
- return netdev;
-}
-EXPORT_SYMBOL(devm_alloc_etherdev_mqs);
-
ssize_t sysfs_format_mac(char *buf, const unsigned char *addr, int len)
{
return scnprintf(buf, PAGE_SIZE, "%*phC\n", len, addr);
--
2.25.0
^ permalink raw reply related
* Re: [PATCH v2 4/5] net: devres: provide devm_register_netdev()
From: Markus Elfring @ 2020-05-23 14:34 UTC (permalink / raw)
To: Bartosz Golaszewski, devicetree, linux-arm-kernel, linux-mediatek,
netdev
Cc: Andrew Perepech, Arnd Bergmann, Bartosz Golaszewski,
Jonathan Corbet, David S. Miller, Edwin Peer, Fabien Parent,
Heiner Kallweit, John Crispin, Jakub Kicinski, Mark Lee,
Matthias Brugger, Pedro Tsai, Sean Wang, Stephane Le Provost,
linux-kernel, kernel-janitors
…
> +++ b/net/devres.c
> @@ -38,3 +38,58 @@ struct net_device *devm_alloc_etherdev_mqs(struct device *dev, int sizeof_priv,
…
> + * This is a devres variant of register_netdev() for which the unregister
> + * function will be call automatically when the managing device is
Is the following wording variant more appropriate?
+ * function will be automatically called when the managing device is
Regards,
Markus
^ permalink raw reply
* Re: [RFC PATCH net-next 4/4] net: dp83869: Add RGMII internal delay configuration
From: Andrew Lunn @ 2020-05-23 14:58 UTC (permalink / raw)
To: Dan Murphy
Cc: f.fainelli, hkallweit1, davem, robh, netdev, linux-kernel,
devicetree
In-Reply-To: <20200521174834.3234-5-dmurphy@ti.com>
On Thu, May 21, 2020 at 12:48:34PM -0500, 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..40c34fefffe4 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",
> + &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;
> + }
Hi Dan
Seems like the helper should be doing the range check, and printing
the message. It should be common to all PHY drivers using delays
looked up in a list.
I also wonder about putting the of_property_read_u32 inside a
helper. Something like
of_get_phy_rgmii_delays(struct device_node *np, phy_interface_t interface,
u32 *rx_delay, u32 *tx_delay)
And maybe a third helper which combines phy_get_delay_index() and
of_get_phy_rgmii_delays().
> +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. */
No. As i said last time, default to 2ns, if there is no specific delay
value in DT.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 4/4] net: dp83869: Add RGMII internal delay configuration
From: Andrew Lunn @ 2020-05-23 15:09 UTC (permalink / raw)
To: Dan Murphy
Cc: Florian Fainelli, hkallweit1, davem, robh, netdev, linux-kernel,
devicetree
In-Reply-To: <948bfa24-97ad-ba35-f06c-25846432e506@ti.com>
> > > + 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.
Hi Dan
I'm not sure the helper is implementing the best behaviour. Rounded to
the nearest when within the supported range is O.K. But if the request
is outside the range, i would report an error.
Any why is your PHY special, in that is does care about out of range
delays, when others using new the new core helper don't?
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 1/4] dt-bindings: net: Add tx and rx internal delays
From: Andrew Lunn @ 2020-05-23 15:13 UTC (permalink / raw)
To: Dan Murphy
Cc: f.fainelli, hkallweit1, davem, robh, netdev, linux-kernel,
devicetree
In-Reply-To: <20200522122534.3353-2-dmurphy@ti.com>
On Fri, May 22, 2020 at 07:25:31AM -0500, Dan Murphy wrote:
> tx-internal-delays and rx-internal-delays are a common setting for RGMII
> capable devices.
>
> These properties are used when the phy-mode or phy-controller is set to
> rgmii-id, rgmii-rxid or rgmii-txid. These modes indicate to the
> controller that the PHY will add the internal delay for the connection.
>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> ---
>
> v2 - updated to add -ps
>
> .../bindings/net/ethernet-controller.yaml | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
> index ac471b60ed6a..70702a4ef5e8 100644
> --- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml
> +++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
> @@ -143,6 +143,20 @@ properties:
> Specifies the PHY management type. If auto is set and fixed-link
> is not specified, it uses MDIO for management.
>
> + rx-internal-delay-ps:
> + $ref: /schemas/types.yaml#definitions/uint32
> + description: |
> + RGMII Receive PHY Clock Delay defined in pico seconds. This is used for
> + PHY's that have configurable RX internal delays. This property is only
> + used when the phy-mode or phy-connection-type is rgmii-id or rgmii-rxid.
Hi Dan
Please add a comment about rounding to the nearest supported value.
Andrew
^ permalink raw reply
* [PATCH] arm64: dts: qcom: sm8250: change ufs node name to ufshc
From: Jonathan Marek @ 2020-05-23 17:52 UTC (permalink / raw)
To: linux-arm-msm
Cc: Andy Gross, Bjorn Andersson, Rob Herring,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
The ufs-qcom driver checks that the name matches the androidboot.bootdevice
parameter provided by the bootloader, which uses the name ufshc. Without
this change UFS fails to probe.
I think this is broken behavior from the ufs-qcom driver, but using the
name ufshc is consistent with dts for sdm845/sm8150/etc.
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index e0344d3ba159..3bdce658c08a 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -309,7 +309,7 @@ uart2: serial@a90000 {
};
};
- ufs_mem_hc: ufs@1d84000 {
+ ufs_mem_hc: ufshc@1d84000 {
compatible = "qcom,sm8250-ufshc", "qcom,ufshc",
"jedec,ufs-2.0";
reg = <0 0x01d84000 0 0x3000>;
--
2.26.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox