* Здравствуйте! Вас интересуют клиентские базы данных?
From: devicetree @ 2019-07-08 13:54 UTC (permalink / raw)
To: RvzBdevicetree
Здравствуйте! Вас интересуют клиентские базы данных?
^ permalink raw reply
* Re: [PATCH] net: hisilicon: Add an tx_desc to adapt HI13X1_GMAC
From: David Miller @ 2019-07-08 18:18 UTC (permalink / raw)
To: xiaojiangfeng
Cc: yisen.zhuang, salil.mehta, dingtianhong, robh+dt, mark.rutland,
netdev, devicetree, linux-kernel, leeyou.li, xiekunxun,
jianping.liu, nixiaoming
In-Reply-To: <20190707.221805.2104668553072088371.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Sun, 07 Jul 2019 22:18:05 -0700 (PDT)
> From: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
> Date: Fri, 5 Jul 2019 14:10:03 +0800
>
>> HI13X1 changed the offsets and bitmaps for tx_desc
>> registers in the same peripheral device on different
>> models of the hip04_eth.
>>
>> Signed-off-by: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
>
> Applied.
Actually I didn't apply this because I can't see that HI13X1_GMAC
kconfig knob anywhere in the tree at all.
^ permalink raw reply
* Re: [PATCH 17/60] dt-bindings: Add legacy 'toppoly' vendor prefix
From: Rob Herring @ 2019-07-08 19:00 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Mark Rutland, devicetree, Maxime Ripard, Sebastian Reichel,
dri-devel, Tomi Valkeinen, Sean Paul
In-Reply-To: <20190707181937.6250-14-laurent.pinchart@ideasonboard.com>
On Sun, Jul 7, 2019 at 12:25 PM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> The 'toppoly' vendor prefix is in use and refers to TPO, whose DT vendor
> prefix is already defined as 'tpo'. Add 'toppoly' as an alternative and
> document it as legacy.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index 2514463f2c63..d78527eb8254 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -867,6 +867,8 @@ patternProperties:
> description: Tecon Microprocessor Technologies, LLC.
> "^topeet,.*":
> description: Topeet
> + "^toppoly,.*":
> + description: TPO (legacy prefix, see 'tpo')
Add 'deprecated: true' also. That's a new property in json-schema
draft8. It's not used for anything yet other than documentation.
Rob
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 2/2] backlight: arcxcnn: add "arctic" vendor prefix
From: Brian Dodge @ 2019-07-08 19:05 UTC (permalink / raw)
To: Dan Murphy
Cc: devicetree, Daniel Thompson, jingoohan1, dri-devel, robh+dt,
jacek.anaszewski, Pavel Machek, pbacon, lee.jones, linux-leds
In-Reply-To: <c7b8da82-e492-db1e-5a02-e4a36df6a6f2@ti.com>
[-- Attachment #1.1: Type: text/plain, Size: 4774 bytes --]
Thanks. pSemi purchased ArcticSand a few years ago so they are the same
legal entity. I will ask them if they want to retain the original copyright
notice
On Mon, Jul 8, 2019, 2:05 PM Dan Murphy <dmurphy@ti.com> wrote:
> Brian
>
> On 6/30/19 7:28 PM, Brian Dodge wrote:
> > The original patch adding this driver and DT bindings improperly
> > used "arc" as the vendor-prefix. This adds "arctic" which is the
> > proper prefix and retains "arc" to allow existing users of the
> > "arc" prefix to update to new kernels. There is at least one
> > (Samsung Chromebook Plus)
> >
> > Signed-off-by: Brian Dodge <bdodge09@gmail.com>
> > Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
> > ---
> > drivers/video/backlight/arcxcnn_bl.c | 41
> +++++++++++++++++++++++++++---------
> > 1 file changed, 31 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/video/backlight/arcxcnn_bl.c
> b/drivers/video/backlight/arcxcnn_bl.c
> > index 7b1c0a0..a419554 100644
> > --- a/drivers/video/backlight/arcxcnn_bl.c
> > +++ b/drivers/video/backlight/arcxcnn_bl.c
> > @@ -1,9 +1,9 @@
> > // SPDX-License-Identifier: GPL-2.0-only
> > /*
> > - * Backlight driver for ArcticSand ARC_X_C_0N_0N Devices
> > + * Backlight driver for pSemi (formerly ArcticSand) ARC_X_C_0N_0N
> Devices
> > *
> > - * Copyright 2016 ArcticSand, Inc.
> > - * Author : Brian Dodge <bdodge@arcticsand.com>
>
> I know you are the original author from ArcticSand but did pSemi
> actually own the copyright in 2016?
>
> I don't think this is a big issue just wondering if we should retain the
> ArcticSand copyright as well.
>
> Probably a question for your legal department.
>
> Otherwise
>
> Reviewed-by: Dan Murphy <dmurphy@ti.com>
>
> > + * Copyright 2016-2019 pSemi, Inc.
> > + * Author : Brian Dodge <bdodge@psemi.com>
> > */
> >
> > #include <linux/backlight.h>
> > @@ -191,27 +191,46 @@ static void arcxcnn_parse_dt(struct arcxcnn *lp)
> > if (ret == 0)
> > lp->pdata->initial_brightness = prog_val;
> >
> > - ret = of_property_read_u32(node, "arc,led-config-0", &prog_val);
> > + ret = of_property_read_u32(node, "arctic,led-config-0", &prog_val);
> > + if (ret)
> > + ret = of_property_read_u32(node, "arc,led-config-0",
> &prog_val);
> > +
> > if (ret == 0)
> > lp->pdata->led_config_0 = (u8)prog_val;
> >
> > - ret = of_property_read_u32(node, "arc,led-config-1", &prog_val);
> > + ret = of_property_read_u32(node, "arctic,led-config-1", &prog_val);
> > + if (ret)
> > + ret = of_property_read_u32(node, "arc,led-config-1",
> &prog_val);
> > +
> > if (ret == 0)
> > lp->pdata->led_config_1 = (u8)prog_val;
> >
> > - ret = of_property_read_u32(node, "arc,dim-freq", &prog_val);
> > + ret = of_property_read_u32(node, "arctic,dim-freq", &prog_val);
> > + if (ret)
> > + ret = of_property_read_u32(node, "arc,dim-freq",
> &prog_val);
> > +
> > if (ret == 0)
> > lp->pdata->dim_freq = (u8)prog_val;
> >
> > - ret = of_property_read_u32(node, "arc,comp-config", &prog_val);
> > + ret = of_property_read_u32(node, "arctic,comp-config", &prog_val);
> > + if (ret)
> > + ret = of_property_read_u32(node, "arc,comp-config",
> &prog_val);
> > +
> > if (ret == 0)
> > lp->pdata->comp_config = (u8)prog_val;
> >
> > - ret = of_property_read_u32(node, "arc,filter-config", &prog_val);
> > + ret = of_property_read_u32(node, "arctic,filter-config",
> &prog_val);
> > + if (ret)
> > + ret = of_property_read_u32(node,
> > + "arc,filter-config", &prog_val);
> > +
> > if (ret == 0)
> > lp->pdata->filter_config = (u8)prog_val;
> >
> > - ret = of_property_read_u32(node, "arc,trim-config", &prog_val);
> > + ret = of_property_read_u32(node, "arctic,trim-config", &prog_val);
> > + if (ret)
> > + ret = of_property_read_u32(node, "arc,trim-config",
> &prog_val);
> > +
> > if (ret == 0)
> > lp->pdata->trim_config = (u8)prog_val;
> >
> > @@ -381,6 +400,8 @@ static int arcxcnn_remove(struct i2c_client *cl)
> > }
> >
> > static const struct of_device_id arcxcnn_dt_ids[] = {
> > + { .compatible = "arctic,arc2c0608" },
> > + /* here to remain compatible with an older binding, do not use */
> > { .compatible = "arc,arc2c0608" },
> > { }
> > };
> > @@ -404,5 +425,5 @@ static struct i2c_driver arcxcnn_driver = {
> > module_i2c_driver(arcxcnn_driver);
> >
> > MODULE_LICENSE("GPL v2");
> > -MODULE_AUTHOR("Brian Dodge <bdodge@arcticsand.com>");
> > +MODULE_AUTHOR("Brian Dodge <bdodge@psemi.com>");
> > MODULE_DESCRIPTION("ARCXCNN Backlight driver");
>
[-- Attachment #1.2: Type: text/html, Size: 6905 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH v3 0/7] net: phy: realtek: Enable configuration of RTL8211E LEDs and SSC
From: Matthias Kaehlcke @ 2019-07-08 19:24 UTC (permalink / raw)
To: David S . Miller, Rob Herring, Mark Rutland, Andrew Lunn,
Florian Fainelli, Heiner Kallweit
Cc: netdev, devicetree, linux-kernel, Douglas Anderson,
Matthias Kaehlcke
The Realtek RTL8211E allows customization of the PHY LED behavior,
like which LEDs are on for certain link speeds and which LEDs blink
when there is traffic. By default EEE LED mode is enabled, in which
a blinking LED is on for 400ms and off for 2s. This series adds
support for configuring the LED behavior through device tree
properties.
The RTL8211E supports Spread Spectrum Clocking (SSC), which reduces
clock noise that may affect other board functions. By default SSC
is disabled, this series adds support for enabling it through a
device tree property.
Certain registers on the RTL8211E can only be accessed through
a vendor specific extended page mechanism. Extended pages need
to be accessed for the LED configuration and enabling SSC. This
series adds helpers to facilitate accessing extended pages.
Matthias Kaehlcke (7):
dt-bindings: net: Add bindings for Realtek PHYs
net: phy: realtek: Allow disabling RTL8211E EEE LED mode
dt-bindings: net: realtek: Add property to enable SSC
net: phy: realtek: Add helpers for accessing RTL8211E extension pages
net: phy: realtek: Support SSC for the RTL8211E
dt-bindings: net: realtek: Add property to configure LED mode
net: phy: realtek: configure RTL8211E LEDs
.../devicetree/bindings/net/realtek.txt | 47 +++++
drivers/net/phy/realtek.c | 171 ++++++++++++++++--
include/dt-bindings/net/realtek.h | 18 ++
3 files changed, 221 insertions(+), 15 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/realtek.txt
create mode 100644 include/dt-bindings/net/realtek.h
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply
* [PATCH v3 1/7] dt-bindings: net: Add bindings for Realtek PHYs
From: Matthias Kaehlcke @ 2019-07-08 19:24 UTC (permalink / raw)
To: David S . Miller, Rob Herring, Mark Rutland, Andrew Lunn,
Florian Fainelli, Heiner Kallweit
Cc: netdev, devicetree, linux-kernel, Douglas Anderson,
Matthias Kaehlcke
In-Reply-To: <20190708192459.187984-1-mka@chromium.org>
Add the 'realtek,eee-led-mode-disable' property to disable EEE
LED mode on Realtek PHYs that support it.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
---
TODO: adapt PHY core to deal with optional compatible strings
Changes in v3:
- added entry for compatible string
- added compatible string to example
- mention that the new property is only available for RTL8211E
Changes in v2:
- document 'realtek,eee-led-mode-disable' instead of
'realtek,enable-ssc' in the initial version
---
.../devicetree/bindings/net/realtek.txt | 31 +++++++++++++++++++
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/realtek.txt
diff --git a/Documentation/devicetree/bindings/net/realtek.txt b/Documentation/devicetree/bindings/net/realtek.txt
new file mode 100644
index 000000000000..db0333f23fec
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/realtek.txt
@@ -0,0 +1,31 @@
+Realtek PHY properties.
+
+This document describes properties of Realtek PHYs.
+
+Optional properties:
+- compatible: should be one of the following:
+ "realtek,rtl8201cp", "realtek,rtl8201f", "realtek,rtl8211",
+ "realtek,rtl8211b", "realtek,rtl8211c", "realtek,rtl8211dn",
+ "realtek,rtl8211e", "realtek,rtl8211f", "rtl8366rb"
+
+ the property is required if any of the properties are specified that
+ are only supported for certain Realtek PHYs.
+
+- realtek,eee-led-mode-disable: Disable EEE LED mode on this port.
+
+ Only supported for "realtek,rtl8211e".
+
+
+Example:
+
+mdio0 {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy: ethernet-phy@1 {
+ compatible = "realtek,rtl8211e";
+ reg = <1>;
+ realtek,eee-led-mode-disable;
+ };
+};
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
* [PATCH v3 2/7] net: phy: realtek: Allow disabling RTL8211E EEE LED mode
From: Matthias Kaehlcke @ 2019-07-08 19:24 UTC (permalink / raw)
To: David S . Miller, Rob Herring, Mark Rutland, Andrew Lunn,
Florian Fainelli, Heiner Kallweit
Cc: netdev, devicetree, linux-kernel, Douglas Anderson,
Matthias Kaehlcke
In-Reply-To: <20190708192459.187984-1-mka@chromium.org>
EEE LED mode is enabled by default on the RTL8211E. Disable it when
the device tree property 'realtek,eee-led-mode-disable' exists.
The magic values to disable EEE LED mode were taken from the RTL8211E
datasheet, unfortunately they are not further documented.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
---
TODO: DT validation
Changes in v3:
- don't have two versions of rtl8211e_config_init()
(was due to my dev kernel being 4.19, which doesn't have
this function yet)
- changed return type of rtl8211e_disable_eee_led_mode() to void
- added empty line after rtl8211e_config_init()
Changes in v2:
- patch added to the series
---
drivers/net/phy/realtek.c | 31 ++++++++++++++++++++++++++++++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index a669945eb829..827ea7ed080d 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -9,8 +9,9 @@
* Copyright (c) 2004 Freescale Semiconductor, Inc.
*/
#include <linux/bitops.h>
-#include <linux/phy.h>
#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/phy.h>
#define RTL821x_PHYSR 0x11
#define RTL821x_PHYSR_DUPLEX BIT(13)
@@ -26,6 +27,10 @@
#define RTL821x_EXT_PAGE_SELECT 0x1e
#define RTL821x_PAGE_SELECT 0x1f
+/* RTL8211E page 5 */
+#define RTL8211E_EEE_LED_MODE1 0x05
+#define RTL8211E_EEE_LED_MODE2 0x06
+
#define RTL8211F_INSR 0x1d
#define RTL8211F_TX_DELAY BIT(8)
@@ -53,6 +58,26 @@ static int rtl821x_write_page(struct phy_device *phydev, int page)
return __phy_write(phydev, RTL821x_PAGE_SELECT, page);
}
+static void rtl8211e_disable_eee_led_mode(struct phy_device *phydev)
+{
+ int oldpage;
+ int err = 0;
+
+ oldpage = phy_select_page(phydev, 5);
+ if (oldpage < 0)
+ goto out;
+
+ /* write magic values to disable EEE LED mode */
+ err = __phy_write(phydev, RTL8211E_EEE_LED_MODE1, 0x8b82);
+ if (err)
+ goto out;
+
+ err = __phy_write(phydev, RTL8211E_EEE_LED_MODE2, 0x052b);
+
+out:
+ phy_restore_page(phydev, oldpage, err);
+}
+
static int rtl8201_ack_interrupt(struct phy_device *phydev)
{
int err;
@@ -184,9 +209,13 @@ static int rtl8211f_config_init(struct phy_device *phydev)
static int rtl8211e_config_init(struct phy_device *phydev)
{
+ struct device *dev = &phydev->mdio.dev;
int ret = 0, oldpage;
u16 val;
+ if (of_property_read_bool(dev->of_node, "realtek,eee-led-mode-disable"))
+ rtl8211e_disable_eee_led_mode(phydev);
+
/* enable TX/RX delay for rgmii-* modes, and disable them for rgmii. */
switch (phydev->interface) {
case PHY_INTERFACE_MODE_RGMII:
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
* [PATCH v3 3/7] dt-bindings: net: realtek: Add property to enable SSC
From: Matthias Kaehlcke @ 2019-07-08 19:24 UTC (permalink / raw)
To: David S . Miller, Rob Herring, Mark Rutland, Andrew Lunn,
Florian Fainelli, Heiner Kallweit
Cc: netdev, devicetree, linux-kernel, Douglas Anderson,
Matthias Kaehlcke
In-Reply-To: <20190708192459.187984-1-mka@chromium.org>
Add the 'realtek,enable-ssc' property to enable Spread Spectrum
Clocking (SSC) on Realtek PHYs that support it.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
---
Changes in v3:
- changed wording for supported PHY models
Changes in v2:
- patch added to the series (kind of, it already existed, but now
the binding is created by another patch)
---
Documentation/devicetree/bindings/net/realtek.txt | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/realtek.txt b/Documentation/devicetree/bindings/net/realtek.txt
index db0333f23fec..af2824664f08 100644
--- a/Documentation/devicetree/bindings/net/realtek.txt
+++ b/Documentation/devicetree/bindings/net/realtek.txt
@@ -15,6 +15,10 @@ Optional properties:
Only supported for "realtek,rtl8211e".
+- realtek,enable-ssc : Enable Spread Spectrum Clocking (SSC) on this port.
+
+ Only supported for "realtek,rtl8211e".
+
Example:
@@ -27,5 +31,6 @@ mdio0 {
compatible = "realtek,rtl8211e";
reg = <1>;
realtek,eee-led-mode-disable;
+ realtek,enable-ssc;
};
};
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
* [PATCH v3 4/7] net: phy: realtek: Add helpers for accessing RTL8211E extension pages
From: Matthias Kaehlcke @ 2019-07-08 19:24 UTC (permalink / raw)
To: David S . Miller, Rob Herring, Mark Rutland, Andrew Lunn,
Florian Fainelli, Heiner Kallweit
Cc: netdev, devicetree, linux-kernel, Douglas Anderson,
Matthias Kaehlcke
In-Reply-To: <20190708192459.187984-1-mka@chromium.org>
The RTL8211E has extension pages, which can be accessed after
selecting a page through a custom method. Add a function to
modify bits in a register of an extension page and a helper for
selecting an ext page. Use rtl8211e_modify_ext_paged() in
rtl8211e_config_init() instead of doing things 'manually'.
rtl8211e_modify_ext_paged() is inspired by its counterpart
phy_modify_paged().
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
---
Changes in v3:
- use the new function in rtl8211e_config_init() instead of
doing things 'manually'
- use existing RTL8211E_EXT_PAGE instead of adding a new define
- updated commit message
Changes in v2:
- use phy_select_page() and phy_restore_page(), get rid of
rtl8211e_restore_page()
- s/rtl821e_select_ext_page/rtl8211e_select_ext_page/
- updated commit message
---
drivers/net/phy/realtek.c | 57 +++++++++++++++++++++++++++++----------
1 file changed, 43 insertions(+), 14 deletions(-)
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index 827ea7ed080d..fa11ae5ebd91 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -27,6 +27,8 @@
#define RTL821x_EXT_PAGE_SELECT 0x1e
#define RTL821x_PAGE_SELECT 0x1f
+#define RTL8211E_EXT_PAGE 7
+
/* RTL8211E page 5 */
#define RTL8211E_EEE_LED_MODE1 0x05
#define RTL8211E_EEE_LED_MODE2 0x06
@@ -58,6 +60,44 @@ static int rtl821x_write_page(struct phy_device *phydev, int page)
return __phy_write(phydev, RTL821x_PAGE_SELECT, page);
}
+static int rtl8211e_select_ext_page(struct phy_device *phydev, int page)
+{
+ int ret, oldpage;
+
+ oldpage = phy_select_page(phydev, RTL8211E_EXT_PAGE);
+ if (oldpage < 0)
+ return oldpage;
+
+ ret = __phy_write(phydev, RTL821x_EXT_PAGE_SELECT, page);
+ if (ret)
+ return phy_restore_page(phydev, page, ret);
+
+ return 0;
+}
+
+static int rtl8211e_modify_ext_paged(struct phy_device *phydev, int page,
+ u32 regnum, u16 mask, u16 set)
+{
+ int ret = 0;
+ int oldpage;
+ int new;
+
+ oldpage = rtl8211e_select_ext_page(phydev, page);
+ if (oldpage < 0)
+ goto out;
+
+ ret = __phy_read(phydev, regnum);
+ if (ret < 0)
+ goto out;
+
+ new = (ret & ~mask) | set;
+ if (new != ret)
+ ret = __phy_write(phydev, regnum, new);
+
+out:
+ return phy_restore_page(phydev, oldpage, ret);
+}
+
static void rtl8211e_disable_eee_led_mode(struct phy_device *phydev)
{
int oldpage;
@@ -210,7 +250,6 @@ static int rtl8211f_config_init(struct phy_device *phydev)
static int rtl8211e_config_init(struct phy_device *phydev)
{
struct device *dev = &phydev->mdio.dev;
- int ret = 0, oldpage;
u16 val;
if (of_property_read_bool(dev->of_node, "realtek,eee-led-mode-disable"))
@@ -242,19 +281,9 @@ static int rtl8211e_config_init(struct phy_device *phydev)
* 2 = RX Delay, 1 = TX Delay, 0 = SELRGV (see original PHY datasheet
* for details).
*/
- oldpage = phy_select_page(phydev, 0x7);
- if (oldpage < 0)
- goto err_restore_page;
-
- ret = __phy_write(phydev, RTL821x_EXT_PAGE_SELECT, 0xa4);
- if (ret)
- goto err_restore_page;
-
- ret = __phy_modify(phydev, 0x1c, RTL8211E_TX_DELAY | RTL8211E_RX_DELAY,
- val);
-
-err_restore_page:
- return phy_restore_page(phydev, oldpage, ret);
+ return rtl8211e_modify_ext_paged(phydev, 0xa4, 0x1c,
+ RTL8211E_TX_DELAY | RTL8211E_RX_DELAY,
+ val);
}
static int rtl8211b_suspend(struct phy_device *phydev)
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
* [PATCH v3 5/7] net: phy: realtek: Support SSC for the RTL8211E
From: Matthias Kaehlcke @ 2019-07-08 19:24 UTC (permalink / raw)
To: David S . Miller, Rob Herring, Mark Rutland, Andrew Lunn,
Florian Fainelli, Heiner Kallweit
Cc: netdev, devicetree, linux-kernel, Douglas Anderson,
Matthias Kaehlcke
In-Reply-To: <20190708192459.187984-1-mka@chromium.org>
By default Spread-Spectrum Clocking (SSC) is disabled on the RTL8211E.
Enable it if the device tree property 'realtek,enable-ssc' exists.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
---
TODO: DT validation
Changes in v3:
- use phydev_err() instead of dev_err()
Changes in v2:
- enable SSC in config_init() instead of probe()
- fixed error check after enabling SSC
---
drivers/net/phy/realtek.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index fa11ae5ebd91..5854412403b5 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -9,6 +9,7 @@
* Copyright (c) 2004 Freescale Semiconductor, Inc.
*/
#include <linux/bitops.h>
+#include <linux/device.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/phy.h>
@@ -33,6 +34,10 @@
#define RTL8211E_EEE_LED_MODE1 0x05
#define RTL8211E_EEE_LED_MODE2 0x06
+/* RTL8211E extension page 160 */
+#define RTL8211E_SCR 0x1a
+#define RTL8211E_SCR_DISABLE_RXC_SSC BIT(2)
+
#define RTL8211F_INSR 0x1d
#define RTL8211F_TX_DELAY BIT(8)
@@ -250,8 +255,18 @@ static int rtl8211f_config_init(struct phy_device *phydev)
static int rtl8211e_config_init(struct phy_device *phydev)
{
struct device *dev = &phydev->mdio.dev;
+ int ret;
u16 val;
+ if (of_property_read_bool(dev->of_node, "realtek,enable-ssc")) {
+ ret = rtl8211e_modify_ext_paged(phydev, 0xa0, RTL8211E_SCR,
+ RTL8211E_SCR_DISABLE_RXC_SSC,
+ 0);
+ if (ret < 0)
+ phydev_err(phydev, "failed to enable SSC on RXC: %d\n",
+ ret);
+ }
+
if (of_property_read_bool(dev->of_node, "realtek,eee-led-mode-disable"))
rtl8211e_disable_eee_led_mode(phydev);
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
* [PATCH v3 6/7] dt-bindings: net: realtek: Add property to configure LED mode
From: Matthias Kaehlcke @ 2019-07-08 19:24 UTC (permalink / raw)
To: David S . Miller, Rob Herring, Mark Rutland, Andrew Lunn,
Florian Fainelli, Heiner Kallweit
Cc: netdev, devicetree, linux-kernel, Douglas Anderson,
Matthias Kaehlcke
In-Reply-To: <20190708192459.187984-1-mka@chromium.org>
The LED behavior of some Realtek PHYs is configurable. Add the
property 'realtek,led-modes' to specify the configuration of the
LEDs.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
---
Changes in v3:
- added RTL8211E_LED_OFF to LED modes
- changed wording for supported PHY models
Changes in v2:
- patch added to the series
---
.../devicetree/bindings/net/realtek.txt | 11 +++++++++++
include/dt-bindings/net/realtek.h | 18 ++++++++++++++++++
2 files changed, 29 insertions(+)
create mode 100644 include/dt-bindings/net/realtek.h
diff --git a/Documentation/devicetree/bindings/net/realtek.txt b/Documentation/devicetree/bindings/net/realtek.txt
index af2824664f08..ab218f2b7653 100644
--- a/Documentation/devicetree/bindings/net/realtek.txt
+++ b/Documentation/devicetree/bindings/net/realtek.txt
@@ -19,6 +19,14 @@ Optional properties:
Only supported for "realtek,rtl8211e".
+- realtek,led-modes: LED mode configuration.
+
+ A 0..3 element vector, with each element configuring the operating
+ mode of an LED. Omitted LEDs are turned off. Allowed values are
+ defined in "include/dt-bindings/net/realtek.h".
+
+ Only supported for "realtek,rtl8211e".
+
Example:
@@ -32,5 +40,8 @@ mdio0 {
reg = <1>;
realtek,eee-led-mode-disable;
realtek,enable-ssc;
+ realtek,led-modes = <RTL8211E_LINK_ACTIVITY
+ RTL8211E_LINK_100
+ RTL8211E_LINK_1000>;
};
};
diff --git a/include/dt-bindings/net/realtek.h b/include/dt-bindings/net/realtek.h
new file mode 100644
index 000000000000..023cb776a7a3
--- /dev/null
+++ b/include/dt-bindings/net/realtek.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _DT_BINDINGS_REALTEK_H
+#define _DT_BINDINGS_REALTEK_H
+
+/* LED modes for RTL8211E PHY */
+
+#define RTL8211E_LED_OFF 0
+#define RTL8211E_LINK_10 1
+#define RTL8211E_LINK_100 2
+#define RTL8211E_LINK_1000 4
+#define RTL8211E_LINK_10_100 3
+#define RTL8211E_LINK_10_1000 5
+#define RTL8211E_LINK_100_1000 6
+#define RTL8211E_LINK_10_100_1000 7
+
+#define RTL8211E_LINK_ACTIVITY (1 << 16)
+
+#endif
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
* [PATCH v3 7/7] net: phy: realtek: configure RTL8211E LEDs
From: Matthias Kaehlcke @ 2019-07-08 19:24 UTC (permalink / raw)
To: David S . Miller, Rob Herring, Mark Rutland, Andrew Lunn,
Florian Fainelli, Heiner Kallweit
Cc: netdev, devicetree, linux-kernel, Douglas Anderson,
Matthias Kaehlcke
In-Reply-To: <20190708192459.187984-1-mka@chromium.org>
Configure the RTL8211E LEDs behavior when the device tree property
'realtek,led-modes' is specified.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
---
TODO: DT validation
Changes in v3:
- sanity check led-modes values
- set LACR bits in a more readable way
- use phydev_err() instead of dev_err()
- log an error if LED configuration fails
Changes in v2:
- patch added to the series
---
drivers/net/phy/realtek.c | 72 +++++++++++++++++++++++++++++++++++++--
1 file changed, 70 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index 5854412403b5..e9fb67654c4e 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -9,10 +9,12 @@
* Copyright (c) 2004 Freescale Semiconductor, Inc.
*/
#include <linux/bitops.h>
+#include <linux/bits.h>
#include <linux/device.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/phy.h>
+#include <dt-bindings/net/realtek.h>
#define RTL821x_PHYSR 0x11
#define RTL821x_PHYSR_DUPLEX BIT(13)
@@ -34,6 +36,15 @@
#define RTL8211E_EEE_LED_MODE1 0x05
#define RTL8211E_EEE_LED_MODE2 0x06
+/* RTL8211E extension page 44 */
+#define RTL8211E_LACR 0x1a
+#define RLT8211E_LACR_LEDACTCTRL_SHIFT 4
+#define RLT8211E_LACR_LEDACTCTRL_MASK GENMASK(6, 4)
+#define RTL8211E_LCR 0x1c
+#define RTL8211E_LCR_LEDCTRL_MASK (GENMASK(2, 0) | \
+ GENMASK(6, 4) | \
+ GENMASK(10, 8))
+
/* RTL8211E extension page 160 */
#define RTL8211E_SCR 0x1a
#define RTL8211E_SCR_DISABLE_RXC_SSC BIT(2)
@@ -123,6 +134,62 @@ static void rtl8211e_disable_eee_led_mode(struct phy_device *phydev)
phy_restore_page(phydev, oldpage, err);
}
+static int rtl8211e_config_leds(struct phy_device *phydev)
+{
+ struct device *dev = &phydev->mdio.dev;
+ int count, i, oldpage, ret;
+ u16 lacr_bits = 0, lcr_bits = 0;
+
+ if (!dev->of_node)
+ return 0;
+
+ if (of_property_read_bool(dev->of_node, "realtek,eee-led-mode-disable"))
+ rtl8211e_disable_eee_led_mode(phydev);
+
+ count = of_property_count_elems_of_size(dev->of_node,
+ "realtek,led-modes",
+ sizeof(u32));
+ if (count < 0 || count > 3)
+ return -EINVAL;
+
+ for (i = 0; i < count; i++) {
+ u32 val;
+
+ of_property_read_u32_index(dev->of_node,
+ "realtek,led-modes", i, &val);
+ if ((val > RTL8211E_LINK_10_100_1000 &&
+ val < RTL8211E_LINK_ACTIVITY) ||
+ val > (RTL8211E_LINK_ACTIVITY | RTL8211E_LINK_10_100_1000))
+ return -EINVAL;
+
+ if (val & RTL8211E_LINK_ACTIVITY)
+ lacr_bits |= BIT(RLT8211E_LACR_LEDACTCTRL_SHIFT + i);
+
+ lcr_bits |= (u16)(val & 0xf) << (i * 4);
+ }
+
+ oldpage = rtl8211e_select_ext_page(phydev, 44);
+ if (oldpage < 0) {
+ phydev_err(phydev, "failed to select extended page: %d\n", oldpage);
+ goto err;
+ }
+
+ ret = __phy_modify(phydev, RTL8211E_LACR,
+ RLT8211E_LACR_LEDACTCTRL_MASK, lacr_bits);
+ if (ret) {
+ phydev_err(phydev, "failed to write LACR reg: %d\n", ret);
+ goto err;
+ }
+
+ ret = __phy_modify(phydev, RTL8211E_LCR,
+ RTL8211E_LCR_LEDCTRL_MASK, lcr_bits);
+ if (ret)
+ phydev_err(phydev, "failed to write LCR reg: %d\n", ret);
+
+err:
+ return phy_restore_page(phydev, oldpage, ret);
+}
+
static int rtl8201_ack_interrupt(struct phy_device *phydev)
{
int err;
@@ -267,8 +334,9 @@ static int rtl8211e_config_init(struct phy_device *phydev)
ret);
}
- if (of_property_read_bool(dev->of_node, "realtek,eee-led-mode-disable"))
- rtl8211e_disable_eee_led_mode(phydev);
+ ret = rtl8211e_config_leds(phydev);
+ if (ret)
+ phydev_err(phydev, "LED configuration failed: %d\n", ret);
/* enable TX/RX delay for rgmii-* modes, and disable them for rgmii. */
switch (phydev->interface) {
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
* Re: [PATCH v4 1/5] dt-bindings: interconnect: Add Qualcomm QCS404 DT bindings
From: Bjorn Andersson @ 2019-07-08 19:26 UTC (permalink / raw)
To: Georgi Djakov
Cc: robh+dt, agross, vkoul, evgreen, daidavid1, linux-pm, devicetree,
linux-kernel, linux-arm-msm
In-Reply-To: <20190613151323.10850-2-georgi.djakov@linaro.org>
On Thu 13 Jun 08:13 PDT 2019, Georgi Djakov wrote:
> The Qualcomm QCS404 platform has several buses that could be controlled
> and tuned according to the bandwidth demand.
>
> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
> ---
>
> v4:
> - Add the DT header into this patch.
> - Pick Bjorn's r-b.
>
> v3:
> - Add a reg property and move the interconnect nodes under the "soc" node.
>
> v2:
> - No changes.
>
> .../bindings/interconnect/qcom,qcs404.txt | 46 ++++++++++
> .../dt-bindings/interconnect/qcom,qcs404.h | 88 +++++++++++++++++++
> 2 files changed, 134 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/interconnect/qcom,qcs404.txt
> create mode 100644 include/dt-bindings/interconnect/qcom,qcs404.h
>
> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,qcs404.txt b/Documentation/devicetree/bindings/interconnect/qcom,qcs404.txt
> new file mode 100644
> index 000000000000..14a827268dda
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interconnect/qcom,qcs404.txt
> @@ -0,0 +1,46 @@
> +Qualcomm QCS404 Network-On-Chip interconnect driver binding
> +-----------------------------------------------------------
> +
> +Required properties :
> +- compatible : shall contain only one of the following:
> + "qcom,qcs404-bimc"
> + "qcom,qcs404-pcnoc"
> + "qcom,qcs404-snoc"
> +- #interconnect-cells : should contain 1
> +
> +Optional properties :
> +reg : specifies the physical base address and size of registers
> +clocks : list of phandles and specifiers to all interconnect bus clocks
> +clock-names : clock names should include both "bus_clk" and "bus_a_clk"
Spoke to Rob about this patch, and I don't think these properties should
not be described as optional.
The reg isn't used unless we're implementing support for QoS, but let's
include them in the binding as required anyways.
Iirc the two clocks are required with the current implementation, but
shouldn't there be an iface clock as well, for accessing the QoS
register space?
PS. As I read this again, please drop _clk from the two clocks names -
we know they are clocks...
Regards,
Bjorn
> +
> +Example:
> +
> +soc {
> + ...
> + bimc: interconnect@400000 {
> + reg = <0x00400000 0x80000>;
> + compatible = "qcom,qcs404-bimc";
> + #interconnect-cells = <1>;
> + clock-names = "bus_clk", "bus_a_clk";
> + clocks = <&rpmcc RPM_SMD_BIMC_CLK>,
> + <&rpmcc RPM_SMD_BIMC_A_CLK>;
> + };
> +
> + pnoc: interconnect@500000 {
> + reg = <0x00500000 0x15080>;
> + compatible = "qcom,qcs404-pcnoc";
> + #interconnect-cells = <1>;
> + clock-names = "bus_clk", "bus_a_clk";
> + clocks = <&rpmcc RPM_SMD_PNOC_CLK>,
> + <&rpmcc RPM_SMD_PNOC_A_CLK>;
> + };
> +
> + snoc: interconnect@580000 {
> + reg = <0x00580000 0x23080>;
> + compatible = "qcom,qcs404-snoc";
> + #interconnect-cells = <1>;
> + clock-names = "bus_clk", "bus_a_clk";
> + clocks = <&rpmcc RPM_SMD_SNOC_CLK>,
> + <&rpmcc RPM_SMD_SNOC_A_CLK>;
> + };
> +};
> diff --git a/include/dt-bindings/interconnect/qcom,qcs404.h b/include/dt-bindings/interconnect/qcom,qcs404.h
> new file mode 100644
> index 000000000000..960f6e39c5f2
> --- /dev/null
> +++ b/include/dt-bindings/interconnect/qcom,qcs404.h
> @@ -0,0 +1,88 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Qualcomm interconnect IDs
> + *
> + * Copyright (c) 2019, Linaro Ltd.
> + * Author: Georgi Djakov <georgi.djakov@linaro.org>
> + */
> +
> +#ifndef __DT_BINDINGS_INTERCONNECT_QCOM_QCS404_H
> +#define __DT_BINDINGS_INTERCONNECT_QCOM_QCS404_H
> +
> +#define MASTER_AMPSS_M0 0
> +#define MASTER_OXILI 1
> +#define MASTER_MDP_PORT0 2
> +#define MASTER_SNOC_BIMC_1 3
> +#define MASTER_TCU_0 4
> +#define SLAVE_EBI_CH0 5
> +#define SLAVE_BIMC_SNOC 6
> +
> +#define MASTER_SPDM 0
> +#define MASTER_BLSP_1 1
> +#define MASTER_BLSP_2 2
> +#define MASTER_XI_USB_HS1 3
> +#define MASTER_CRYPT0 4
> +#define MASTER_SDCC_1 5
> +#define MASTER_SDCC_2 6
> +#define MASTER_SNOC_PCNOC 7
> +#define MASTER_QPIC 8
> +#define PCNOC_INT_0 9
> +#define PCNOC_INT_2 10
> +#define PCNOC_INT_3 11
> +#define PCNOC_S_0 12
> +#define PCNOC_S_1 13
> +#define PCNOC_S_2 14
> +#define PCNOC_S_3 15
> +#define PCNOC_S_4 16
> +#define PCNOC_S_6 17
> +#define PCNOC_S_7 18
> +#define PCNOC_S_8 19
> +#define PCNOC_S_9 20
> +#define PCNOC_S_10 21
> +#define PCNOC_S_11 22
> +#define SLAVE_SPDM 23
> +#define SLAVE_PDM 24
> +#define SLAVE_PRNG 25
> +#define SLAVE_TCSR 26
> +#define SLAVE_SNOC_CFG 27
> +#define SLAVE_MESSAGE_RAM 28
> +#define SLAVE_DISP_SS_CFG 29
> +#define SLAVE_GPU_CFG 30
> +#define SLAVE_BLSP_1 31
> +#define SLAVE_BLSP_2 32
> +#define SLAVE_TLMM_NORTH 33
> +#define SLAVE_PCIE 34
> +#define SLAVE_ETHERNET 35
> +#define SLAVE_TLMM_EAST 36
> +#define SLAVE_TCU 37
> +#define SLAVE_PMIC_ARB 38
> +#define SLAVE_SDCC_1 39
> +#define SLAVE_SDCC_2 40
> +#define SLAVE_TLMM_SOUTH 41
> +#define SLAVE_USB_HS 42
> +#define SLAVE_USB3 43
> +#define SLAVE_CRYPTO_0_CFG 44
> +#define SLAVE_PCNOC_SNOC 45
> +
> +#define MASTER_QDSS_BAM 0
> +#define MASTER_BIMC_SNOC 1
> +#define MASTER_PCNOC_SNOC 2
> +#define MASTER_QDSS_ETR 3
> +#define MASTER_EMAC 4
> +#define MASTER_PCIE 5
> +#define MASTER_USB3 6
> +#define QDSS_INT 7
> +#define SNOC_INT_0 8
> +#define SNOC_INT_1 9
> +#define SNOC_INT_2 10
> +#define SLAVE_KPSS_AHB 11
> +#define SLAVE_WCSS 12
> +#define SLAVE_SNOC_BIMC_1 13
> +#define SLAVE_IMEM 14
> +#define SLAVE_SNOC_PCNOC 15
> +#define SLAVE_QDSS_STM 16
> +#define SLAVE_CATS_0 17
> +#define SLAVE_CATS_1 18
> +#define SLAVE_LPASS 19
> +
> +#endif
^ permalink raw reply
* Re: [PATCH v3 1/7] dt-bindings: net: Add bindings for Realtek PHYs
From: Andrew Lunn @ 2019-07-08 19:46 UTC (permalink / raw)
To: Matthias Kaehlcke
Cc: David S . Miller, Rob Herring, Mark Rutland, Florian Fainelli,
Heiner Kallweit, netdev, devicetree, linux-kernel,
Douglas Anderson
In-Reply-To: <20190708192459.187984-2-mka@chromium.org>
On Mon, Jul 08, 2019 at 12:24:53PM -0700, Matthias Kaehlcke wrote:
> Add the 'realtek,eee-led-mode-disable' property to disable EEE
> LED mode on Realtek PHYs that support it.
>
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> ---
> TODO: adapt PHY core to deal with optional compatible strings
Yes. Does this even work at the moment? I would expect
of_mdiobus_child_is_phy() to return false, indicating the device is
not actually a PHY.
Andrew
^ permalink raw reply
* Re: [PATCH v3 6/7] dt-bindings: net: realtek: Add property to configure LED mode
From: Andrew Lunn @ 2019-07-08 19:48 UTC (permalink / raw)
To: Matthias Kaehlcke
Cc: David S . Miller, Rob Herring, Mark Rutland, Florian Fainelli,
Heiner Kallweit, netdev, devicetree, linux-kernel,
Douglas Anderson
In-Reply-To: <20190708192459.187984-7-mka@chromium.org>
On Mon, Jul 08, 2019 at 12:24:58PM -0700, Matthias Kaehlcke wrote:
> The LED behavior of some Realtek PHYs is configurable. Add the
> property 'realtek,led-modes' to specify the configuration of the
> LEDs.
>
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Hi Matthias
Humm. I thought you were going to drop this and the next patch?
Andrew
^ permalink raw reply
* Re: [PATCH v3 1/7] dt-bindings: net: Add bindings for Realtek PHYs
From: Matthias Kaehlcke @ 2019-07-08 20:01 UTC (permalink / raw)
To: Andrew Lunn
Cc: David S . Miller, Rob Herring, Mark Rutland, Florian Fainelli,
Heiner Kallweit, netdev, devicetree, linux-kernel,
Douglas Anderson
In-Reply-To: <20190708194615.GH9027@lunn.ch>
On Mon, Jul 08, 2019 at 09:46:15PM +0200, Andrew Lunn wrote:
> On Mon, Jul 08, 2019 at 12:24:53PM -0700, Matthias Kaehlcke wrote:
> > Add the 'realtek,eee-led-mode-disable' property to disable EEE
> > LED mode on Realtek PHYs that support it.
> >
> > Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> > ---
> > TODO: adapt PHY core to deal with optional compatible strings
>
> Yes. Does this even work at the moment? I would expect
> of_mdiobus_child_is_phy() to return false, indicating the device is
> not actually a PHY.
Indeed, it currently doesn't work atm. I found that removing the check
for dev->of_node in of_mdiobus_link_mdiodev() helps, but I imagine
doing (only) this might have undesired side-effects.
^ permalink raw reply
* Re: [PATCH v3 6/7] dt-bindings: net: realtek: Add property to configure LED mode
From: Matthias Kaehlcke @ 2019-07-08 20:07 UTC (permalink / raw)
To: Andrew Lunn
Cc: David S . Miller, Rob Herring, Mark Rutland, Florian Fainelli,
Heiner Kallweit, netdev, devicetree, linux-kernel,
Douglas Anderson
In-Reply-To: <20190708194834.GI9027@lunn.ch>
Hi Andrew,
On Mon, Jul 08, 2019 at 09:48:34PM +0200, Andrew Lunn wrote:
> On Mon, Jul 08, 2019 at 12:24:58PM -0700, Matthias Kaehlcke wrote:
> > The LED behavior of some Realtek PHYs is configurable. Add the
> > property 'realtek,led-modes' to specify the configuration of the
> > LEDs.
> >
> > Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
>
> Hi Matthias
>
> Humm. I thought you were going to drop this and the next patch?
It wasn't clear to me whether not introducing a generic interface is a
definitive NACK and tought I could at least post a version with the
review comments addressed. If there is no way forward without a
generic interface I'll drop the two patches.
^ permalink raw reply
* Re: [PATCH] of/platform: Drop superfluous cast in of_device_make_bus_id()
From: Rob Herring @ 2019-07-08 20:07 UTC (permalink / raw)
Cc: Frank Rowand, devicetree, linux-kernel, Geert Uytterhoeven
In-Reply-To: <20190624124620.21891-1-geert+renesas@glider.be>
On Mon, 24 Jun 2019 14:46:20 +0200, Geert Uytterhoeven wrote:
> There is no need to cast "u64" to "unsigned long long" before printing
> it, as both types have been made identical on all architectures many
> years ago.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> drivers/of/platform.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
Applied, thanks.
Rob
^ permalink raw reply
* Re: [PATCH v6 01/18] kunit: test: add KUnit test runner core
From: Brendan Higgins @ 2019-07-08 20:40 UTC (permalink / raw)
To: Luis Chamberlain
Cc: Petr Mladek, open list:DOCUMENTATION, Peter Zijlstra,
Amir Goldstein, dri-devel, Sasha Levin, Masahiro Yamada,
Michael Ellerman, open list:KERNEL SELFTEST FRAMEWORK, shuah,
linux-nvdimm, Frank Rowand, Knut Omang, Kieran Bingham, wfg,
Joel Stanley, David Rientjes, Jeff Dike, Dan Carpenter,
devicetree, linux-kbuild,
"Bird, Timothy" <Tim.Bird>
In-Reply-To: <CAFd5g45cF9rYc8YupnCgd=7xz_yW+_TMp_L+cSFUBW7d9njnVQ@mail.gmail.com>
On Mon, Jul 8, 2019 at 11:08 AM Brendan Higgins
<brendanhiggins@google.com> wrote:
>
> On Fri, Jul 5, 2019 at 1:15 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
> >
> > On Wed, Jul 03, 2019 at 05:35:58PM -0700, Brendan Higgins wrote:
> > > Add core facilities for defining unit tests; this provides a common way
> > > to define test cases, functions that execute code which is under test
> > > and determine whether the code under test behaves as expected; this also
> > > provides a way to group together related test cases in test suites (here
> > > we call them test_modules).
> > >
> > > Just define test cases and how to execute them for now; setting
> > > expectations on code will be defined later.
> > >
> > > Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
> > > Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
> >
> > Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
> >
> > But a nitpick below, I think that can be fixed later with a follow up
> > patch.
> >
> > > +/**
> > > + * struct kunit - represents a running instance of a test.
> > > + * @priv: for user to store arbitrary data. Commonly used to pass data created
> > > + * in the init function (see &struct kunit_suite).
> > > + *
> > > + * Used to store information about the current context under which the test is
> > > + * running. Most of this data is private and should only be accessed indirectly
> > > + * via public functions; the one exception is @priv which can be used by the
> > > + * test writer to store arbitrary data.
> > > + *
> > > + * A brief note on locking:
> > > + *
> > > + * First off, we need to lock because in certain cases a user may want to use an
> > > + * expectation in a thread other than the thread that the test case is running
> > > + * in.
> >
> > This as a prefix to the struct without a lock seems odd. It would be
> > clearer I think if you'd explain here what locking mechanism we decided
> > to use and why it suffices today.
>
> Whoops, sorry this should have been in the next patch. Will fix.
Err..no, this shouldn't be here at all. Sorry about that. I just need
to rewrite the comment.
> > > +/**
> > > + * suite_test() - used to register a &struct kunit_suite with KUnit.
> >
> > You mean kunit_test_suite()?
>
> Yep, sorry about that. Will fix.
>
> > > + * @suite: a statically allocated &struct kunit_suite.
> > > + *
> > > + * Registers @suite with the test framework. See &struct kunit_suite for more
> > > + * information.
> > > + *
> > > + * NOTE: Currently KUnit tests are all run as late_initcalls; this means that
> > > + * they cannot test anything where tests must run at a different init phase. One
> > > + * significant restriction resulting from this is that KUnit cannot reliably
> > > + * test anything that is initialize in the late_init phase.
> > initialize prior to the late init phase.
> >
> >
> > That is, this is useless to test things running early.
>
> Yeah, I can add that phrasing in.
>
> > > + *
> > > + * TODO(brendanhiggins@google.com): Don't run all KUnit tests as late_initcalls.
> > > + * I have some future work planned to dispatch all KUnit tests from the same
> > > + * place, and at the very least to do so after everything else is definitely
> > > + * initialized.
> >
> > TODOs are odd to be adding to documentation, this is just not common
> > place practice. The NOTE should suffice for you.
>
> Because it is a kernel doc? Would you usually make a separate
> non-kernel doc comment for a TODO? I guess that makes sense.
>
> Thanks!
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v3 1/7] dt-bindings: net: Add bindings for Realtek PHYs
From: Andrew Lunn @ 2019-07-08 21:13 UTC (permalink / raw)
To: Matthias Kaehlcke
Cc: David S . Miller, Rob Herring, Mark Rutland, Florian Fainelli,
Heiner Kallweit, netdev, devicetree, linux-kernel,
Douglas Anderson
In-Reply-To: <20190708200136.GM250418@google.com>
On Mon, Jul 08, 2019 at 01:01:36PM -0700, Matthias Kaehlcke wrote:
> On Mon, Jul 08, 2019 at 09:46:15PM +0200, Andrew Lunn wrote:
> > On Mon, Jul 08, 2019 at 12:24:53PM -0700, Matthias Kaehlcke wrote:
> > > Add the 'realtek,eee-led-mode-disable' property to disable EEE
> > > LED mode on Realtek PHYs that support it.
> > >
> > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> > > ---
> > > TODO: adapt PHY core to deal with optional compatible strings
> >
> > Yes. Does this even work at the moment? I would expect
> > of_mdiobus_child_is_phy() to return false, indicating the device is
> > not actually a PHY.
>
> Indeed, it currently doesn't work atm. I found that removing the check
> for dev->of_node in of_mdiobus_link_mdiodev() helps, but I imagine
> doing (only) this might have undesired side-effects.
O.K.
Please put RFC in patches like this which don't actually work and so
should not be merged. We don't want David accidentally merging them!
Andrew
^ permalink raw reply
* Re: [PATCH v2 1/2] media: dt-bindings: add bindings for Toshiba TC358746
From: Rob Herring @ 2019-07-08 21:17 UTC (permalink / raw)
To: Marco Felsch
Cc: sakari.ailus, mchehab, Jacopo Mondi, devicetree, graphics,
linux-media
In-Reply-To: <20190619152838.25079-2-m.felsch@pengutronix.de>
On Wed, Jun 19, 2019 at 05:28:37PM +0200, Marco Felsch wrote:
> Add corresponding dt-bindings for the Toshiba tc358746 device and update
> the MAINTAINERS file too.
>
> Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
> ---
> Hi Rob,
>
> I droped your reviewed-by tag since there where several changes.
>
> Changes
> v2:
> - use the Documentation/devicetree/bindings/media/ti,omap3isp.txt
> formatting scheme
> - Adapt introducing paragraph according Jacopo's comments
> - drop the clock-names property
> - drop the clock-lanes (csi-2) property
> - adapt the property descriptions accroding Jacopo's comments
> - use port@0 as input and port@1 as output port instead of mapping
> port@0 to parallel and port@1 to csi-2 interface
> - Adapt port/endpoint description according Jacopo's and Sakari's
> comments
> - Adapt the example
> - squash v1 patch-3 and patch-1
> - set status to Maintained
>
> .../bindings/media/i2c/toshiba,tc358746.txt | 95 +++++++++++++++++++
> MAINTAINERS | 7 ++
> 2 files changed, 102 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.txt
One nit below, otherwise:
Reviewed-by: Rob Herring <robh@kernel.org>
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.txt b/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.txt
> new file mode 100644
> index 000000000000..e79b45ee050e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.txt
> @@ -0,0 +1,95 @@
> +Toshiba TC358746 Parallel to MIPI CSI2-TX or MIPI CSI2-RX to Parallel Bridge
> +============================================================================
> +
> +The Toshiba TC358746 converts a parallel into a MIPI CSI-2 stream. The direction
> +can be either parallel-in -> csi-out e.g. to connect a parallel camera to a
> +MIPI CSI-2 host or csi-in -> parallel-out e.g. to connect a parallel display to
> +a MIPI CSI-2 host. It's programmable trough I2C and SPI. The SPI interface is
> +only supported in parallel-in -> csi-out mode.
> +
> +Required properties
> +-------------------
> +
> +- compatible : Shall be "toshiba,tc358746"
> +- reg : Shall be <0x0e>
> +- clocks : Phandle to the reference clock source
> +
> +Optional properties
> +-------------------
> +
> +- reset-gpios : Phandle to the GPIO connected to the reset input pin
> +
> +Port nodes (required)
> +=====================
> +
> +The device node must contain two ports children nodes which should be grouped
> +within a 'ports' node. The first port describes the input connection, the second
> +one describes the output one. Each port shall contain one endpoint subnode that
> +connects to a remote device and specifies the bus type of the input and output
> +ports. Only one endpoint per port shall be present.
> +
> +More documentation on these bindings is available in [1].
> +
> +reg : The interface:
> + 0 - Input, either parallel or MIPI CSI-2
> + 1 - Output, either parallel or MIPI CSI-2
> +
> +Endpoint nodes (required)
> +=========================
> +
> +Required properties
> +-------------------
> +
> +- bus-width : Look at [1] for more information (Parallel endpoint)
> +- data-lanes : Look at [1] for more information (CSI-2 endpoint)
> +- link-frequencies : Array of frequencies the driver can choose to
> + full-fill the parallel timings calculation. Look at
> + [1] for more information (CSI-2 endpoint)
> +
> +Optional properties
> +-------------------
> +
> +- bus-type : Look at [1] for more information
> +- clock-noncontinuous : Look at [1] for more information (CSI-2 endpoint)
> +
> +[1] Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Example
> +=======
> +
> +&i2c {
> + csi-bridge@0e {
csi-bridge@e
> + reg = <0x0e>;
> + compatible = "toshiba,tc358746";
> + pinctrl-names = "default";
> + clocks = <&clk_cam_ref>;
> + reset-gpios = <&gpio3 2 GPIO_ACTIVE_LOW>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* Input */
> + port@0 {
> + reg = <0>;
> +
> + tc358746_parallel_in: endpoint {
> + bus-width = <8>;
> + remote-endpoint = <µn_parallel_out>;
> + };
> + };
> +
> + /* Output */
> + port@1 {
> + reg = <1>;
> +
> + tc358746_mipi2_out: endpoint {
> + remote-endpoint = <&mipi_csi2_in>;
> + data-lanes = <1 2>;
> + clock-noncontinuous;
> + link-frequencies = /bits/ 64 <216000000>;
> + };
> + };
> + };
> + };
> +};
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 57f496cff999..833b3c8fb301 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -15955,6 +15955,13 @@ S: Maintained
> F: drivers/media/i2c/tc358743*
> F: include/media/i2c/tc358743.h
>
> +TOSHIBA TC358746 DRIVER
> +M: Marco Felsch <kernel@pengutronix.de>
> +L: linux-media@vger.kernel.org
> +S: Maintained
> +F: drivers/media/i2c/tc358746*
> +F: Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.txt
> +
> TOSHIBA WMI HOTKEYS DRIVER
> M: Azael Avalos <coproscefalo@gmail.com>
> L: platform-driver-x86@vger.kernel.org
> --
> 2.20.1
>
^ permalink raw reply
* Re: [PATCH] media: dt-bindings: rockchip: Document RK3328 VPU binding
From: Rob Herring @ 2019-07-08 21:22 UTC (permalink / raw)
Cc: Ezequiel Garcia, Mauro Carvalho Chehab, Heiko Stuebner,
Jonas Karlman, Mark Rutland, Hans Verkuil,
linux-media@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <VI1PR03MB4206A833FF54A3235571896CAC1F0@VI1PR03MB4206.eurprd03.prod.outlook.com>
On Wed, 29 May 2019 10:54:27 +0000, Jonas Karlman wrote:
> Update devicetree binding documentation for Rockchip VPU on RK3328.
>
> Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
> ---
> .../devicetree/bindings/media/rockchip-vpu.txt | 18 ++++++++++++++++--
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: mmc: add DT bindings for Milbeaut SD controller
From: Rob Herring @ 2019-07-08 21:26 UTC (permalink / raw)
To: Takao Orito
Cc: ulf.hansson, mark.rutland, linux-mmc, devicetree, linux-kernel,
masami.hiramatsu, jaswinder.singh, sugaya.taichi, kasai.kazuhiro,
kanematsu.shinji
In-Reply-To: <1559208131-426-1-git-send-email-orito.takao@socionext.com>
On Thu, May 30, 2019 at 06:22:11PM +0900, Takao Orito wrote:
> Add the device-tree binding documentation for Milbeaut SDHCI driver.
>
> Signed-off-by: Takao Orito <orito.takao@socionext.com>
> ---
> .../devicetree/bindings/mmc/sdhci-milbeaut.txt | 32 ++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-milbeaut.txt
>
> diff --git a/Documentation/devicetree/bindings/mmc/sdhci-milbeaut.txt b/Documentation/devicetree/bindings/mmc/sdhci-milbeaut.txt
> new file mode 100644
> index 0000000..6063116
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/sdhci-milbeaut.txt
> @@ -0,0 +1,32 @@
> +* SOCIONEXT Milbeaut SDHCI controller
> +
> +This file documents differences between the core properties in mmc.txt
> +and the properties used by the sdhci_milbeaut driver.
> +
> +Required properties:
> +- compatible: "socionext,milbeaut-m10v-sdhci-3.0"
> +- clocks: Must contain an entry for each entry in clock-names. It is a
> + list of phandles and clock-specifier pairs.
> + See ../clocks/clock-bindings.txt for details.
> +- clock-names: Should contain the following two entries:
> + "iface" - clock used for sdhci interface
> + "core" - core clock for sdhci controller
> +- vmmc-supply: a phandle of a fixed GPIO regulator
Being a fixed GPIO regulator is board specific and outside the scope of
the binding. Otherwise,
Reviewed-by: Rob Herring <robh@kernel.org>
> +
> +Optional properties:
> +- fujitsu,cmd-dat-delay-select: boolean property indicating that this host
> + requires the CMD_DAT_DELAY control to be enabled.
> +
> +Example:
> + sdhci3: mmc@1b010000 {
> + compatible = "socionext,milbeaut-m10v-sdhci-3.0";
> + reg = <0x1b010000 0x10000>;
> + interrupts = <0 265 0x4>;
> + voltage-ranges = <3300 3300>;
> + bus-width = <4>;
> + clocks = <&clk 7>, <&ahb_clk>;
> + clock-names = "core", "iface";
> + cap-sdio-irq;
> + vmmc-supply = <&vcc_sdhci3>;
> + fujitsu,cmd-dat-delay-select;
> + };
> --
> 1.9.1
>
>
^ permalink raw reply
* Re: [PATCH] of/fdt: pass early_init_dt_reserve_memory_arch() with bool type nomap
From: Rob Herring @ 2019-07-08 21:28 UTC (permalink / raw)
Cc: devicetree, Frank Rowand, Masahiro Yamada, linux-kernel
In-Reply-To: <20190530103927.20952-1-yamada.masahiro@socionext.com>
On Thu, 30 May 2019 19:39:27 +0900, Masahiro Yamada wrote:
> The third argument 'nomap' of early_init_dt_reserve_memory_arch() is
> bool. It is preferred to pass it with a bool type parameter.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
>
> drivers/of/fdt.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
Applied, thanks.
Rob
^ permalink raw reply
* Re: [PATCH V5 net-next 4/6] dt-bindings: ptp: Introduce MII time stamping devices.
From: Rob Herring @ 2019-07-08 21:38 UTC (permalink / raw)
To: Richard Cochran
Cc: netdev, David Miller, devicetree, Andrew Lunn, Florian Fainelli,
Jacob Keller, Mark Rutland, Miroslav Lichvar, Willem de Bruijn
In-Reply-To: <d786656435c64160d50014beb3d3d9d1aaf6f22d.1559281985.git.richardcochran@gmail.com>
On Thu, May 30, 2019 at 10:56:24PM -0700, Richard Cochran wrote:
> This patch add a new binding that allows non-PHY MII time stamping
> devices to find their buses. The new documentation covers both the
> generic binding and one upcoming user.
>
> Signed-off-by: Richard Cochran <richardcochran@gmail.com>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> ---
> Documentation/devicetree/bindings/ptp/ptp-ines.txt | 35 ++++++++++++++++++
> .../devicetree/bindings/ptp/timestamper.txt | 41 ++++++++++++++++++++++
> 2 files changed, 76 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/ptp/ptp-ines.txt
> create mode 100644 Documentation/devicetree/bindings/ptp/timestamper.txt
>
> diff --git a/Documentation/devicetree/bindings/ptp/ptp-ines.txt b/Documentation/devicetree/bindings/ptp/ptp-ines.txt
> new file mode 100644
> index 000000000000..4dee9eb89455
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ptp/ptp-ines.txt
> @@ -0,0 +1,35 @@
> +ZHAW InES PTP time stamping IP core
> +
> +The IP core needs two different kinds of nodes. The control node
> +lives somewhere in the memory map and specifies the address of the
> +control registers. There can be up to three port handles placed as
> +attributes of PHY nodes. These associate a particular MII bus with a
> +port index within the IP core.
> +
> +Required properties of the control node:
> +
> +- compatible: "ines,ptp-ctrl"
This is an IP block that gets integrated into SoCs? It's not very
specific given that there could be different versions of the IP block
and SoC vendors can integrate various versions of the IP block in their
own unique (i.e. buggy) way.
> +- reg: physical address and size of the register bank
> +
> +Required format of the port handle within the PHY node:
> +
> +- timestamper: provides control node reference and
> + the port channel within the IP core
> +
> +Example:
> +
> + tstamper: timestamper@60000000 {
> + compatible = "ines,ptp-ctrl";
> + reg = <0x60000000 0x80>;
> + };
> +
> + ethernet@80000000 {
> + ...
> + mdio {
> + ...
> + phy@3 {
ethernet-phy is the correct node name.
> + ...
> + timestamper = <&tstamper 0>;
> + };
> + };
> + };
> diff --git a/Documentation/devicetree/bindings/ptp/timestamper.txt b/Documentation/devicetree/bindings/ptp/timestamper.txt
> new file mode 100644
> index 000000000000..88ea0bc7d662
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ptp/timestamper.txt
> @@ -0,0 +1,41 @@
> +Time stamps from MII bus snooping devices
> +
> +This binding supports non-PHY devices that snoop the MII bus and
> +provide time stamps. In contrast to PHY time stamping drivers (which
> +can simply attach their interface directly to the PHY instance), stand
> +alone MII time stamping drivers use this binding to specify the
> +connection between the snooping device and a given network interface.
> +
> +Non-PHY MII time stamping drivers typically talk to the control
> +interface over another bus like I2C, SPI, UART, or via a memory mapped
> +peripheral. This controller device is associated with one or more
> +time stamping channels, each of which snoops on a MII bus.
> +
> +The "timestamper" property lives in a phy node and links a time
> +stamping channel from the controller device to that phy's MII bus.
> +
> +Example:
> +
> + tstamper: timestamper@10000000 {
> + compatible = "bigcorp,ts-ctrl";
Would be better to use a real example here.
> + };
> +
> + ethernet@20000000 {
> + mdio {
> + phy@1 {
> + timestamper = <&tstamper 0>;
> + };
> + };
> + };
> +
> + ethernet@30000000 {
> + mdio {
> + phy@2 {
> + timestamper = <&tstamper 1>;
> + };
> + };
> + };
> +
> +In this example, time stamps from the MII bus attached to phy@1 will
> +appear on time stamp channel 0 (zero), and those from phy@2 appear on
> +channel 1.
> --
> 2.11.0
>
^ 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