* Re: [PATCH net-next 1/3] net: ethernet: mediatek: add extension of phy-mode for TRGMII
From: Sean Wang @ 2016-09-21 7:33 UTC (permalink / raw)
To: f.fainelli-Re5JQEeQqe8AvxtiuMwx3w
Cc: nbd-p3rKhJxN3npAfugRpC6u6w, keyhaede-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
john-Pj+rj9U5foFAfugRpC6u6w, davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <064d43fb-2942-efd2-6dc7-09f47a256691-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Tue, 20 Sep 2016 14:23:24 -0700, Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>On 09/20/2016 12:59 AM, sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org wrote:
>> From: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>>
>> adds PHY-mode "trgmii" as an extension for the operation
>> mode of the PHY interface, TRGMII can be compatible with
>> RGMII, so the extended mode doesn't really have effects on
>> the target MAC and PHY, is used as the indication if the
>> current MAC is connected to an internal switch or external
>> PHY respectively by the given configuration on the board and
>> then to perform the corresponding setup on TRGMII hardware
>> module.
>
>Based on my googling, it seems like Turbo RGMII is a Mediatek-specific
>thing for now, but this could become standard and used by other vendors
>at some point, so I would be inclined to just extend the phy-mode
>property to support trgmii as another interface type.
>
>If you do so, do you also mind proposing an update to the Device Tree
>specification:
>
>https://www.devicetree.org/specifications/
>
>Thanks!
I am willing to do the these thing
1)
in the next version, I will extend rgmii mode as
another interface type as PHY_INTERFACE_MODE_TRGMII
defined in linux/phy.h instead of extension only inside
the current driver. This change also helps to save some code.
2)
I send another separate patch for updating the Device Tree
specification about TRGMII adding description
are these all okay for you?
^ permalink raw reply
* Re: XDP user interface confusions
From: Jesper Dangaard Brouer via iovisor-dev @ 2016-09-21 7:18 UTC (permalink / raw)
To: Brenden Blanco
Cc: Tom Herbert,
iovisor-dev-9jONkmmOlFHEE9lA1F8Ukti2O/JbrIOy@public.gmane.org,
David Miller, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Daniel Borkmann
In-Reply-To: <20160915185835.GA4418-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, 15 Sep 2016 11:58:35 -0700
Brenden Blanco <bblanco-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org> wrote:
> On Thu, Sep 15, 2016 at 08:14:02PM +0200, Jesper Dangaard Brouer wrote:
> > Hi Brenden,
> >
> > I don't quite understand the semantics of the XDP userspace interface.
> >
> > We allow XDP programs to be (unconditionally) exchanged by another
> > program, this avoids taking the link down+up and avoids reallocating
> > RX ring resources (which is great).
> >
> > We have two XDP samples programs in samples/bpf/ xdp1 and xdp2. Now I
> > want to first load xdp1 and then to avoid the linkdown I load xdp2,
> > and then afterwards remove/stop program xdp1.
> >
> > This does NOT work, because (in samples/bpf/xdp1_user.c) when xdp1
> > exits it unconditionally removes the running XDP program (loaded by xdp2)
> > via set_link_xdp_fd(ifindex, -1). The xdp2 user program is still
> > running, and is unaware of its xdp/bpf program have been unloaded.
> >
> > I find this userspace interface confusing. What this your intention?
> > Perhaps you can explain what the intended semantics or specification is?
>
> In practice, we've used a single agent process to manage bpf programs on
> behalf of the user applications. This agent process uses common linux
> functionalities to add semantics, while not really relying on the bpf
> handles themselves to take care of that. For instance, the process may
> put some lockfiles and what-not in /var/run/$PID, and maybe returns the
> list of running programs through a http: or unix: interface.
>
> So, from a user<->kernel API, the requirements are minimal...the agent
> process just overwrites the loaded bpf program when the application
> changes, or a new application comes online. There is nobody to 'notify'
> when a handle changes.
>
> When translating this into the kernel api that you see now, none of this
> exists, because IMHO the kernel api should be unopinionated and generic.
> The result is something that appears very "fire-and-forget", which
> results in something simple yet safe at the same time; the refcounting
> is done transparently by the kernel.
>
> So, in practice, there is no xdp1 or xdp2, just xdp-agent at different
> points in time. Or, better yet, no agent, just the programs running in
> the kernel, with the handles of the programs residing solely in the
> device, which are perhaps pinned to /sys/fs/bpf for semantic management
> purposes. I didn't feel like it was appropriate to conflate different
> bpf features in the kernel samples, so we don't see (and probably never
> will) a sample which combines these features into a whole. That is best
> left to userspace tools. It so happens that this is one of the projects
> I am currently active on at $DAYJOB, and we fully intend to share the
> details of that when it's in a suitable state.
For the record, I'm not happy with this response.
IHMO the XDP userspace API should have been thought more through. Where
is the specification and documentation for this interface?
There is no official XDP userspace daemon, thus your proposed file-lock
scheme falls apart. We can easily imagine, several different
open-source projects using XDP, they will not coordinate what /var/run
lock-file to use. An admin installs several of these to evaluate
them. Later he gets really confused, because both of them run by
mistake (and it is random who "wins" due to systemd parallel boot).
The programs themselves have no-way to catch this error situation, and
report it. This is the main mistake of this API approach. The admin
also have a hard time debugging this, as our query interface is a bool,
so he just see that some XDP program _is_ running.
Sorry, but we have to do better than this. We have to maintain these
APIs for the next +10 years.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [net-next 01/15] i40e: Introduce VF port representor/control netdevs
From: Or Gerlitz @ 2016-09-21 7:04 UTC (permalink / raw)
To: Samudrala, Sridhar
Cc: Jeff Kirsher, David Miller, Linux Netdev List, nhorman@redhat.com,
sassmann@redhat.com, jogreene@redhat.com, guru.anbalagane,
Ilya Lesokhin, Andy Gospodarek, John Fastabend, Jiri Pirko,
Rony Efraim
In-Reply-To: <57E21E74.5090707@intel.com>
On Wed, Sep 21, 2016 at 8:45 AM, Samudrala, Sridhar
<sridhar.samudrala@intel.com> wrote:
> On 9/20/2016 9:22 PM, Or Gerlitz wrote:
>> On Wed, Sep 21, 2016 at 6:43 AM, Jeff Kirsher
>> <jeffrey.t.kirsher@intel.com> wrote:
>>>
>>> From: Sridhar Samudrala <sridhar.samudrala@intel.com>
>>> This patch enables creation of a VF Port representor/Control netdev
>>> associated with each VF. These netdevs can be used to control and
>>> configure
>>> VFs from PFs namespace. They enable exposing VF statistics, configuring
>>> link state, mtu, fdb/vlan entries etc.
>>
>> What happens if someone does a xmit on the VF representor, does the
>> packet show up @ the VF?
>> and what happens of the VF xmits and there's no HW steering rule that
>> matches this, does
>> the frame show up @ the VF rep on the host?
> TX/RX are not yet supported via VFPR netdevs in this patch series.
> Will be submitting this support in the next patchset.
Okay, good.
>> In other words, can these VF reps serve for setting up host SW based
>> switching which you
>> can later offload (through TC, bridge, netfilter, etc)?
> Yes. These offloads will be possible via VFPRs.
cool
>> I am posing these questions because in downstream patch you are adding
>> devlink support
>> for set/get the e-switch mode and you declare the default mode to be switchdev.
>> When the switchdev mode was introduced in 4.8 these RX/TX
>> characteristics were defined
>> to be an essential (== requirement) part for a driver to support that mode.
> The current patchset introduces the basic VFPR support starting with
> exposing VF stats and syncing link state between VFs and VFPRs.
> We decided to declare the default mode to be switchdev so that the new code
> paths will get exercised by default during normal testing.
so what happens after this patchset is applied and before the future
work is submitted?
RX/TX slow path through the VFPRs isn't supported and what about fast
path? in other words
what happens when someone loads the driver, sets SRIOV (--> the driver
set itself to switchdev mode
and VFPRs are created) and then a VF sends a packet? do you still put
into the HW the legacy DMAC
based switching rules? I am not following...
Or.
^ permalink raw reply
* [v12, 8/8] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
From: Yangbo Lu @ 2016-09-21 6:57 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Scott Wood, Arnd Bergmann
Cc: Mark Rutland, Xiaobo Xie, Minghuan Lian,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Qiang Zhao, Russell King,
Bhupesh Sharma, Jochen Friedrich, Claudiu Manoil,
devicetree-u79uwXL29TY76Z2rM5mHXA, Kumar Gala, Rob Herring,
Santosh Shilimkar,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Leo Li,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Yangbo Lu,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ
In-Reply-To: <1474441040-11946-1-git-send-email-yangbo.lu-3arQi8VN3Tc@public.gmane.org>
The eSDHC of T4240-R1.0-R2.0 has incorrect vender version and spec version.
Acturally the right version numbers should be VVN=0x13 and SVN = 0x1.
This patch adds the GUTS driver support for eSDHC driver to match SoC.
And fix host version to avoid that incorrect version numbers break down
the ADMA data transfer.
Signed-off-by: Yangbo Lu <yangbo.lu-3arQi8VN3Tc@public.gmane.org>
Acked-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Acked-by: Scott Wood <oss-fOR+EgIDQEHk1uMJSBkQmQ@public.gmane.org>
---
Changes for v2:
- Got SVR through iomap instead of dts
Changes for v3:
- Managed GUTS through syscon instead of iomap in eSDHC driver
Changes for v4:
- Got SVR by GUTS driver instead of SYSCON
Changes for v5:
- Changed to get SVR through API fsl_guts_get_svr()
- Combined patch 4, patch 5 and patch 6 into one
Changes for v6:
- Added 'Acked-by: Ulf Hansson'
Changes for v7:
- None
Changes for v8:
- Added 'Acked-by: Scott Wood'
Changes for v9:
- None
Changes for v10:
- None
Changes for v11:
- Changed to use soc_device_match
Changes for v12:
- Matched soc through .family field instead of .soc_id
---
drivers/mmc/host/Kconfig | 1 +
drivers/mmc/host/sdhci-of-esdhc.c | 20 ++++++++++++++++++++
2 files changed, 21 insertions(+)
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 5274f50..a1135a9 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -144,6 +144,7 @@ config MMC_SDHCI_OF_ESDHC
depends on MMC_SDHCI_PLTFM
depends on PPC || ARCH_MXC || ARCH_LAYERSCAPE
select MMC_SDHCI_IO_ACCESSORS
+ select FSL_GUTS
help
This selects the Freescale eSDHC controller support.
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
index fb71c86..57bdb9e 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -18,6 +18,7 @@
#include <linux/of.h>
#include <linux/delay.h>
#include <linux/module.h>
+#include <linux/sys_soc.h>
#include <linux/mmc/host.h>
#include "sdhci-pltfm.h"
#include "sdhci-esdhc.h"
@@ -28,6 +29,7 @@
struct sdhci_esdhc {
u8 vendor_ver;
u8 spec_ver;
+ bool quirk_incorrect_hostver;
};
/**
@@ -73,6 +75,8 @@ static u32 esdhc_readl_fixup(struct sdhci_host *host,
static u16 esdhc_readw_fixup(struct sdhci_host *host,
int spec_reg, u32 value)
{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_esdhc *esdhc = sdhci_pltfm_priv(pltfm_host);
u16 ret;
int shift = (spec_reg & 0x2) * 8;
@@ -80,6 +84,12 @@ static u16 esdhc_readw_fixup(struct sdhci_host *host,
ret = value & 0xffff;
else
ret = (value >> shift) & 0xffff;
+ /* Workaround for T4240-R1.0-R2.0 eSDHC which has incorrect
+ * vendor version and spec version information.
+ */
+ if ((spec_reg == SDHCI_HOST_VERSION) &&
+ (esdhc->quirk_incorrect_hostver))
+ ret = (VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) | SDHCI_SPEC_200;
return ret;
}
@@ -558,6 +568,12 @@ static const struct sdhci_pltfm_data sdhci_esdhc_le_pdata = {
.ops = &sdhci_esdhc_le_ops,
};
+static struct soc_device_attribute soc_incorrect_hostver[] = {
+ { .family = "QorIQ T4240", .revision = "1.0", },
+ { .family = "QorIQ T4240", .revision = "2.0", },
+ { },
+};
+
static void esdhc_init(struct platform_device *pdev, struct sdhci_host *host)
{
struct sdhci_pltfm_host *pltfm_host;
@@ -571,6 +587,10 @@ static void esdhc_init(struct platform_device *pdev, struct sdhci_host *host)
esdhc->vendor_ver = (host_ver & SDHCI_VENDOR_VER_MASK) >>
SDHCI_VENDOR_VER_SHIFT;
esdhc->spec_ver = host_ver & SDHCI_SPEC_VER_MASK;
+ if (soc_device_match(soc_incorrect_hostver))
+ esdhc->quirk_incorrect_hostver = true;
+ else
+ esdhc->quirk_incorrect_hostver = false;
}
static int sdhci_esdhc_probe(struct platform_device *pdev)
--
2.1.0.27.g96db324
^ permalink raw reply related
* [v12, 7/8] base: soc: introduce soc_device_match() interface
From: Yangbo Lu @ 2016-09-21 6:57 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Scott Wood, Arnd Bergmann
Cc: Mark Rutland, Xiaobo Xie, Minghuan Lian,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Qiang Zhao, Russell King,
Bhupesh Sharma, Jochen Friedrich, Claudiu Manoil,
devicetree-u79uwXL29TY76Z2rM5mHXA, Kumar Gala, Rob Herring,
Santosh Shilimkar,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Leo Li,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Yangbo Lu,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ
In-Reply-To: <1474441040-11946-1-git-send-email-yangbo.lu-3arQi8VN3Tc@public.gmane.org>
From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
We keep running into cases where device drivers want to know the exact
version of the a SoC they are currently running on. In the past, this has
usually been done through a vendor specific API that can be called by a
driver, or by directly accessing some kind of version register that is
not part of the device itself but that belongs to a global register area
of the chip.
Common reasons for doing this include:
- A machine is not using devicetree or similar for passing data about
on-chip devices, but just announces their presence using boot-time
platform devices, and the machine code itself does not care about the
revision.
- There is existing firmware or boot loaders with existing DT binaries
with generic compatible strings that do not identify the particular
revision of each device, but the driver knows which SoC revisions
include which part.
- A prerelease version of a chip has some quirks and we are using the same
version of the bootloader and the DT blob on both the prerelease and the
final version. An update of the DT binding seems inappropriate because
that would involve maintaining multiple copies of the dts and/or
bootloader.
This patch introduces the soc_device_match() interface that is meant to
work like of_match_node() but instead of identifying the version of a
device, it identifies the SoC itself using a vendor-agnostic interface.
Unlike of_match_node(), we do not do an exact string compare but instead
use glob_match() to allow wildcards in strings.
Signed-off-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Signed-off-by: Yangbo Lu <yangbo.lu-3arQi8VN3Tc@public.gmane.org>
---
Changes for v11:
- Added this patch for soc match
Changes for v12:
- Corrected the author
- Rewrited soc_device_match with while loop
---
drivers/base/Kconfig | 1 +
drivers/base/soc.c | 66 +++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/sys_soc.h | 3 +++
3 files changed, 70 insertions(+)
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 98504ec..f1591ad2 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -225,6 +225,7 @@ config GENERIC_CPU_AUTOPROBE
config SOC_BUS
bool
+ select GLOB
source "drivers/base/regmap/Kconfig"
diff --git a/drivers/base/soc.c b/drivers/base/soc.c
index 75b98aa..d2fd1ad 100644
--- a/drivers/base/soc.c
+++ b/drivers/base/soc.c
@@ -14,6 +14,7 @@
#include <linux/spinlock.h>
#include <linux/sys_soc.h>
#include <linux/err.h>
+#include <linux/glob.h>
static DEFINE_IDA(soc_ida);
@@ -168,3 +169,68 @@ static void __exit soc_bus_unregister(void)
bus_unregister(&soc_bus_type);
}
module_exit(soc_bus_unregister);
+
+static int soc_device_match_one(struct device *dev, void *arg)
+{
+ struct soc_device *soc_dev = container_of(dev, struct soc_device, dev);
+ const struct soc_device_attribute *match = arg;
+
+ if (match->machine &&
+ !glob_match(match->machine, soc_dev->attr->machine))
+ return 0;
+
+ if (match->family &&
+ !glob_match(match->family, soc_dev->attr->family))
+ return 0;
+
+ if (match->revision &&
+ !glob_match(match->revision, soc_dev->attr->revision))
+ return 0;
+
+ if (match->soc_id &&
+ !glob_match(match->soc_id, soc_dev->attr->soc_id))
+ return 0;
+
+ return 1;
+}
+
+/*
+ * soc_device_match - identify the SoC in the machine
+ * @matches: zero-terminated array of possible matches
+ *
+ * returns the first matching entry of the argument array, or NULL
+ * if none of them match.
+ *
+ * This function is meant as a helper in place of of_match_node()
+ * in cases where either no device tree is available or the information
+ * in a device node is insufficient to identify a particular variant
+ * by its compatible strings or other properties. For new devices,
+ * the DT binding should always provide unique compatible strings
+ * that allow the use of of_match_node() instead.
+ *
+ * The calling function can use the .data entry of the
+ * soc_device_attribute to pass a structure or function pointer for
+ * each entry.
+ */
+const struct soc_device_attribute *soc_device_match(
+ const struct soc_device_attribute *matches)
+{
+ int ret = 0;
+
+ if (!matches)
+ return NULL;
+
+ while (!ret) {
+ if (!(matches->machine || matches->family ||
+ matches->revision || matches->soc_id))
+ break;
+ ret = bus_for_each_dev(&soc_bus_type, NULL, (void *)matches,
+ soc_device_match_one);
+ if (!ret)
+ matches++;
+ else
+ return matches;
+ }
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(soc_device_match);
diff --git a/include/linux/sys_soc.h b/include/linux/sys_soc.h
index 2739ccb..9f5eb06 100644
--- a/include/linux/sys_soc.h
+++ b/include/linux/sys_soc.h
@@ -13,6 +13,7 @@ struct soc_device_attribute {
const char *family;
const char *revision;
const char *soc_id;
+ const void *data;
};
/**
@@ -34,4 +35,6 @@ void soc_device_unregister(struct soc_device *soc_dev);
*/
struct device *soc_device_to_device(struct soc_device *soc);
+const struct soc_device_attribute *soc_device_match(
+ const struct soc_device_attribute *matches);
#endif /* __SOC_BUS_H */
--
2.1.0.27.g96db324
^ permalink raw reply related
* [v12, 6/8] MAINTAINERS: add entry for Freescale SoC drivers
From: Yangbo Lu @ 2016-09-21 6:57 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Scott Wood, Arnd Bergmann
Cc: Mark Rutland, Xiaobo Xie, Minghuan Lian,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Qiang Zhao, Russell King,
Bhupesh Sharma, Jochen Friedrich, Claudiu Manoil,
devicetree-u79uwXL29TY76Z2rM5mHXA, Kumar Gala, Rob Herring,
Santosh Shilimkar,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Leo Li,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Yangbo Lu,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ
In-Reply-To: <1474441040-11946-1-git-send-email-yangbo.lu-3arQi8VN3Tc@public.gmane.org>
Add maintainer entry for Freescale SoC drivers including
the QE library and the GUTS driver now. Also add maintainer
for QE library.
Signed-off-by: Yangbo Lu <yangbo.lu-3arQi8VN3Tc@public.gmane.org>
Acked-by: Scott Wood <oss-fOR+EgIDQEHk1uMJSBkQmQ@public.gmane.org>
Acked-by: Qiang Zhao <qiang.zhao-3arQi8VN3Tc@public.gmane.org>
---
Changes for v8:
- Added this patch
Changes for v9:
- Added linux-arm mail list
- Removed GUTS driver entry
Changes for v10:
- Changed 'DRIVER' to 'DRIVERS'
- Added 'Acked-by' of Scott and Qiang
Changes for v11:
- None
Changes for v12:
- None
---
MAINTAINERS | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 644ff65..33d3683 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4971,9 +4971,18 @@ F: drivers/net/ethernet/freescale/fec_ptp.c
F: drivers/net/ethernet/freescale/fec.h
F: Documentation/devicetree/bindings/net/fsl-fec.txt
+FREESCALE SOC DRIVERS
+M: Scott Wood <oss-fOR+EgIDQEHk1uMJSBkQmQ@public.gmane.org>
+L: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
+L: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
+S: Maintained
+F: drivers/soc/fsl/
+F: include/linux/fsl/
+
FREESCALE QUICC ENGINE LIBRARY
+M: Qiang Zhao <qiang.zhao-3arQi8VN3Tc@public.gmane.org>
L: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
-S: Orphan
+S: Maintained
F: drivers/soc/fsl/qe/
F: include/soc/fsl/*qe*.h
F: include/soc/fsl/*ucc*.h
--
2.1.0.27.g96db324
^ permalink raw reply related
* [v12, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
From: Yangbo Lu @ 2016-09-21 6:57 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Scott Wood, Arnd Bergmann
Cc: Mark Rutland, Xiaobo Xie, Minghuan Lian,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Qiang Zhao, Russell King,
Bhupesh Sharma, Jochen Friedrich, Claudiu Manoil,
devicetree-u79uwXL29TY76Z2rM5mHXA, Kumar Gala, Rob Herring,
Santosh Shilimkar,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Leo Li,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Yangbo Lu,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ
In-Reply-To: <1474441040-11946-1-git-send-email-yangbo.lu-3arQi8VN3Tc@public.gmane.org>
The global utilities block controls power management, I/O device
enabling, power-onreset(POR) configuration monitoring, alternate
function selection for multiplexed signals,and clock control.
This patch adds a driver to manage and access global utilities block.
Initially only reading SVR and registering soc device are supported.
Other guts accesses, such as reading RCW, should eventually be moved
into this driver as well.
Signed-off-by: Yangbo Lu <yangbo.lu-3arQi8VN3Tc@public.gmane.org>
---
Changes for v4:
- Added this patch
Changes for v5:
- Modified copyright info
- Changed MODULE_LICENSE to GPL
- Changed EXPORT_SYMBOL_GPL to EXPORT_SYMBOL
- Made FSL_GUTS user-invisible
- Added a complete compatible list for GUTS
- Stored guts info in file-scope variable
- Added mfspr() getting SVR
- Redefined GUTS APIs
- Called fsl_guts_init rather than using platform driver
- Removed useless parentheses
- Removed useless 'extern' key words
Changes for v6:
- Made guts thread safe in fsl_guts_init
Changes for v7:
- Removed 'ifdef' for function declaration in guts.h
Changes for v8:
- Fixes lines longer than 80 characters checkpatch issue
- Added 'Acked-by: Scott Wood'
Changes for v9:
- None
Changes for v10:
- None
Changes for v11:
- Changed to platform driver
Changes for v12:
- Removed "signed-off-by: Scott"
- Defined fsl_soc_die_attr struct array instead of
soc_device_attribute
- Re-designed soc_device_attribute for QorIQ SoC
- Other minor fixes
---
drivers/soc/Kconfig | 2 +-
drivers/soc/fsl/Kconfig | 19 ++++
drivers/soc/fsl/Makefile | 1 +
drivers/soc/fsl/guts.c | 257 +++++++++++++++++++++++++++++++++++++++++++++++
include/linux/fsl/guts.h | 125 ++++++++++++++---------
5 files changed, 355 insertions(+), 49 deletions(-)
create mode 100644 drivers/soc/fsl/Kconfig
create mode 100644 drivers/soc/fsl/guts.c
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index fe42a2f..f31bceb 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -1,7 +1,7 @@
menu "SOC (System On Chip) specific Drivers"
source "drivers/soc/bcm/Kconfig"
-source "drivers/soc/fsl/qe/Kconfig"
+source "drivers/soc/fsl/Kconfig"
source "drivers/soc/mediatek/Kconfig"
source "drivers/soc/qcom/Kconfig"
source "drivers/soc/rockchip/Kconfig"
diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
new file mode 100644
index 0000000..b99764c
--- /dev/null
+++ b/drivers/soc/fsl/Kconfig
@@ -0,0 +1,19 @@
+#
+# Freescale SOC drivers
+#
+
+source "drivers/soc/fsl/qe/Kconfig"
+
+config FSL_GUTS
+ bool "Freescale QorIQ GUTS driver"
+ select SOC_BUS
+ help
+ The global utilities block controls power management, I/O device
+ enabling, power-onreset(POR) configuration monitoring, alternate
+ function selection for multiplexed signals,and clock control.
+ This driver is to manage and access global utilities block.
+ Initially only reading SVR and registering soc device are supported.
+ Other guts accesses, such as reading RCW, should eventually be moved
+ into this driver as well.
+
+ If you want GUTS driver support, you should say Y here.
diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
index 203307f..02afb7f 100644
--- a/drivers/soc/fsl/Makefile
+++ b/drivers/soc/fsl/Makefile
@@ -4,3 +4,4 @@
obj-$(CONFIG_QUICC_ENGINE) += qe/
obj-$(CONFIG_CPM) += qe/
+obj-$(CONFIG_FSL_GUTS) += guts.o
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
new file mode 100644
index 0000000..2a0e52c
--- /dev/null
+++ b/drivers/soc/fsl/guts.c
@@ -0,0 +1,257 @@
+/*
+ * Freescale QorIQ Platforms GUTS Driver
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/io.h>
+#include <linux/slab.h>
+#include <linux/module.h>
+#include <linux/of_fdt.h>
+#include <linux/sys_soc.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/fsl/guts.h>
+#include <linux/fsl/svr.h>
+
+struct guts {
+ struct ccsr_guts __iomem *regs;
+ bool little_endian;
+};
+
+struct fsl_soc_die_attr {
+ char *die;
+ u32 svr;
+ u32 mask;
+};
+
+static struct guts *guts;
+static struct soc_device_attribute soc_dev_attr;
+static struct soc_device *soc_dev;
+
+
+/* SoC die attribute definition for QorIQ platform */
+static const struct fsl_soc_die_attr fsl_soc_die[] = {
+#ifdef CONFIG_PPC
+ /*
+ * Power Architecture-based SoCs T Series
+ */
+
+ /* Die: T4240, SoC: T4240/T4160/T4080 */
+ { .die = "T4240",
+ .svr = 0x82400000,
+ .mask = 0xfff00000,
+ },
+ /* Die: T1040, SoC: T1040/T1020/T1042/T1022 */
+ { .die = "T1040",
+ .svr = 0x85200000,
+ .mask = 0xfff00000,
+ },
+ /* Die: T2080, SoC: T2080/T2081 */
+ { .die = "T2080",
+ .svr = 0x85300000,
+ .mask = 0xfff00000,
+ },
+ /* Die: T1024, SoC: T1024/T1014/T1023/T1013 */
+ { .die = "T1024",
+ .svr = 0x85400000,
+ .mask = 0xfff00000,
+ },
+#endif /* CONFIG_PPC */
+#if defined(CONFIG_ARCH_MXC) || defined(CONFIG_ARCH_LAYERSCAPE)
+ /*
+ * ARM-based SoCs LS Series
+ */
+
+ /* Die: LS1043A, SoC: LS1043A/LS1023A */
+ { .die = "LS1043A",
+ .svr = 0x87920000,
+ .mask = 0xffff0000,
+ },
+ /* Die: LS2080A, SoC: LS2080A/LS2040A/LS2085A */
+ { .die = "LS2080A",
+ .svr = 0x87010000,
+ .mask = 0xff3f0000,
+ },
+ /* Die: LS1088A, SoC: LS1088A/LS1048A/LS1084A/LS1044A */
+ { .die = "LS1088A",
+ .svr = 0x87030000,
+ .mask = 0xff3f0000,
+ },
+ /* Die: LS1012A, SoC: LS1012A */
+ { .die = "LS1012A",
+ .svr = 0x87040000,
+ .mask = 0xffff0000,
+ },
+ /* Die: LS1046A, SoC: LS1046A/LS1026A */
+ { .die = "LS1046A",
+ .svr = 0x87070000,
+ .mask = 0xffff0000,
+ },
+ /* Die: LS2088A, SoC: LS2088A/LS2048A/LS2084A/LS2044A */
+ { .die = "LS2088A",
+ .svr = 0x87090000,
+ .mask = 0xff3f0000,
+ },
+ /* Die: LS1021A, SoC: LS1021A/LS1020A/LS1022A
+ * Note: Put this die at the end in cause of incorrect identification
+ */
+ { .die = "LS1021A",
+ .svr = 0x87000000,
+ .mask = 0xfff00000,
+ },
+#endif /* CONFIG_ARCH_MXC || CONFIG_ARCH_LAYERSCAPE */
+ { },
+};
+
+static const struct fsl_soc_die_attr *fsl_soc_die_match(
+ u32 svr, const struct fsl_soc_die_attr *matches)
+{
+ while (matches->svr) {
+ if (matches->svr == (svr & matches->mask))
+ return matches;
+ matches++;
+ };
+ return NULL;
+}
+
+u32 fsl_guts_get_svr(void)
+{
+ u32 svr = 0;
+
+ if (!guts || !guts->regs)
+ return svr;
+
+ if (guts->little_endian)
+ svr = ioread32(&guts->regs->svr);
+ else
+ svr = ioread32be(&guts->regs->svr);
+
+ return svr;
+}
+EXPORT_SYMBOL(fsl_guts_get_svr);
+
+static int fsl_guts_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ const struct fsl_soc_die_attr *soc_die;
+ const char *machine;
+ u32 svr;
+ int ret = 0;
+
+ /* Initialize guts */
+ guts = kzalloc(sizeof(*guts), GFP_KERNEL);
+ if (!guts)
+ return -ENOMEM;
+
+ guts->little_endian = of_property_read_bool(np, "little-endian");
+
+ guts->regs = of_iomap(np, 0);
+ if (!guts->regs) {
+ ret = -ENOMEM;
+ goto out_free;
+ }
+
+ /* Register soc device */
+ machine = of_flat_dt_get_machine_name();
+ if (machine)
+ soc_dev_attr.machine = kstrdup(machine, GFP_KERNEL);
+
+ svr = fsl_guts_get_svr();
+ soc_die = fsl_soc_die_match(svr, fsl_soc_die);
+ if (soc_die) {
+ soc_dev_attr.family = kasprintf(GFP_KERNEL, "QorIQ %s",
+ soc_die->die);
+ } else {
+ soc_dev_attr.family = kasprintf(GFP_KERNEL, "QorIQ");
+ }
+ soc_dev_attr.soc_id = kasprintf(GFP_KERNEL, "svr:0x%08x", svr);
+ soc_dev_attr.revision = kasprintf(GFP_KERNEL, "%d.%d",
+ SVR_MAJ(svr), SVR_MIN(svr));
+
+ soc_dev = soc_device_register(&soc_dev_attr);
+ if (IS_ERR(soc_dev)) {
+ ret = PTR_ERR(soc_dev);
+ goto out;
+ }
+ pr_info("Machine: %s\n", soc_dev_attr.machine);
+ pr_info("SoC family: %s\n", soc_dev_attr.family);
+ pr_info("SoC ID: %s, Revision: %s\n",
+ soc_dev_attr.soc_id, soc_dev_attr.revision);
+ return 0;
+out:
+ kfree(soc_dev_attr.machine);
+ kfree(soc_dev_attr.family);
+ kfree(soc_dev_attr.soc_id);
+ kfree(soc_dev_attr.revision);
+ iounmap(guts->regs);
+out_free:
+ kfree(guts);
+ return ret;
+}
+
+static int fsl_guts_remove(struct platform_device *dev)
+{
+ soc_device_unregister(soc_dev);
+ kfree(soc_dev_attr.machine);
+ kfree(soc_dev_attr.family);
+ kfree(soc_dev_attr.soc_id);
+ kfree(soc_dev_attr.revision);
+ iounmap(guts->regs);
+ kfree(guts);
+ return 0;
+}
+
+/*
+ * Table for matching compatible strings, for device tree
+ * guts node, for Freescale QorIQ SOCs.
+ */
+static const struct of_device_id fsl_guts_of_match[] = {
+ { .compatible = "fsl,qoriq-device-config-1.0", },
+ { .compatible = "fsl,qoriq-device-config-2.0", },
+ { .compatible = "fsl,p1010-guts", },
+ { .compatible = "fsl,p1020-guts", },
+ { .compatible = "fsl,p1021-guts", },
+ { .compatible = "fsl,p1022-guts", },
+ { .compatible = "fsl,p1023-guts", },
+ { .compatible = "fsl,p2020-guts", },
+ { .compatible = "fsl,bsc9131-guts", },
+ { .compatible = "fsl,bsc9132-guts", },
+ { .compatible = "fsl,mpc8536-guts", },
+ { .compatible = "fsl,mpc8544-guts", },
+ { .compatible = "fsl,mpc8548-guts", },
+ { .compatible = "fsl,mpc8568-guts", },
+ { .compatible = "fsl,mpc8569-guts", },
+ { .compatible = "fsl,mpc8572-guts", },
+ { .compatible = "fsl,ls1021a-dcfg", },
+ { .compatible = "fsl,ls1043a-dcfg", },
+ { .compatible = "fsl,ls2080a-dcfg", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, fsl_guts_of_match);
+
+static struct platform_driver fsl_guts_driver = {
+ .driver = {
+ .name = "fsl-guts",
+ .of_match_table = fsl_guts_of_match,
+ },
+ .probe = fsl_guts_probe,
+ .remove = fsl_guts_remove,
+};
+
+static int __init fsl_guts_init(void)
+{
+ return platform_driver_register(&fsl_guts_driver);
+}
+core_initcall(fsl_guts_init);
+
+static void __exit fsl_guts_exit(void)
+{
+ platform_driver_unregister(&fsl_guts_driver);
+}
+module_exit(fsl_guts_exit);
diff --git a/include/linux/fsl/guts.h b/include/linux/fsl/guts.h
index 649e917..3efa3b8 100644
--- a/include/linux/fsl/guts.h
+++ b/include/linux/fsl/guts.h
@@ -29,83 +29,112 @@
* #ifdefs.
*/
struct ccsr_guts {
- __be32 porpllsr; /* 0x.0000 - POR PLL Ratio Status Register */
- __be32 porbmsr; /* 0x.0004 - POR Boot Mode Status Register */
- __be32 porimpscr; /* 0x.0008 - POR I/O Impedance Status and Control Register */
- __be32 pordevsr; /* 0x.000c - POR I/O Device Status Register */
- __be32 pordbgmsr; /* 0x.0010 - POR Debug Mode Status Register */
- __be32 pordevsr2; /* 0x.0014 - POR device status register 2 */
+ u32 porpllsr; /* 0x.0000 - POR PLL Ratio Status Register */
+ u32 porbmsr; /* 0x.0004 - POR Boot Mode Status Register */
+ u32 porimpscr; /* 0x.0008 - POR I/O Impedance Status and
+ * Control Register
+ */
+ u32 pordevsr; /* 0x.000c - POR I/O Device Status Register */
+ u32 pordbgmsr; /* 0x.0010 - POR Debug Mode Status Register */
+ u32 pordevsr2; /* 0x.0014 - POR device status register 2 */
u8 res018[0x20 - 0x18];
- __be32 porcir; /* 0x.0020 - POR Configuration Information Register */
+ u32 porcir; /* 0x.0020 - POR Configuration Information
+ * Register
+ */
u8 res024[0x30 - 0x24];
- __be32 gpiocr; /* 0x.0030 - GPIO Control Register */
+ u32 gpiocr; /* 0x.0030 - GPIO Control Register */
u8 res034[0x40 - 0x34];
- __be32 gpoutdr; /* 0x.0040 - General-Purpose Output Data Register */
+ u32 gpoutdr; /* 0x.0040 - General-Purpose Output Data
+ * Register
+ */
u8 res044[0x50 - 0x44];
- __be32 gpindr; /* 0x.0050 - General-Purpose Input Data Register */
+ u32 gpindr; /* 0x.0050 - General-Purpose Input Data
+ * Register
+ */
u8 res054[0x60 - 0x54];
- __be32 pmuxcr; /* 0x.0060 - Alternate Function Signal Multiplex Control */
- __be32 pmuxcr2; /* 0x.0064 - Alternate function signal multiplex control 2 */
- __be32 dmuxcr; /* 0x.0068 - DMA Mux Control Register */
+ u32 pmuxcr; /* 0x.0060 - Alternate Function Signal
+ * Multiplex Control
+ */
+ u32 pmuxcr2; /* 0x.0064 - Alternate function signal
+ * multiplex control 2
+ */
+ u32 dmuxcr; /* 0x.0068 - DMA Mux Control Register */
u8 res06c[0x70 - 0x6c];
- __be32 devdisr; /* 0x.0070 - Device Disable Control */
+ u32 devdisr; /* 0x.0070 - Device Disable Control */
#define CCSR_GUTS_DEVDISR_TB1 0x00001000
#define CCSR_GUTS_DEVDISR_TB0 0x00004000
- __be32 devdisr2; /* 0x.0074 - Device Disable Control 2 */
+ u32 devdisr2; /* 0x.0074 - Device Disable Control 2 */
u8 res078[0x7c - 0x78];
- __be32 pmjcr; /* 0x.007c - 4 Power Management Jog Control Register */
- __be32 powmgtcsr; /* 0x.0080 - Power Management Status and Control Register */
- __be32 pmrccr; /* 0x.0084 - Power Management Reset Counter Configuration Register */
- __be32 pmpdccr; /* 0x.0088 - Power Management Power Down Counter Configuration Register */
- __be32 pmcdr; /* 0x.008c - 4Power management clock disable register */
- __be32 mcpsumr; /* 0x.0090 - Machine Check Summary Register */
- __be32 rstrscr; /* 0x.0094 - Reset Request Status and Control Register */
- __be32 ectrstcr; /* 0x.0098 - Exception reset control register */
- __be32 autorstsr; /* 0x.009c - Automatic reset status register */
- __be32 pvr; /* 0x.00a0 - Processor Version Register */
- __be32 svr; /* 0x.00a4 - System Version Register */
+ u32 pmjcr; /* 0x.007c - 4 Power Management Jog Control
+ * Register
+ */
+ u32 powmgtcsr; /* 0x.0080 - Power Management Status and
+ * Control Register
+ */
+ u32 pmrccr; /* 0x.0084 - Power Management Reset Counter
+ * Configuration Register
+ */
+ u32 pmpdccr; /* 0x.0088 - Power Management Power Down Counter
+ * Configuration Register
+ */
+ u32 pmcdr; /* 0x.008c - 4Power management clock disable
+ * register
+ */
+ u32 mcpsumr; /* 0x.0090 - Machine Check Summary Register */
+ u32 rstrscr; /* 0x.0094 - Reset Request Status and
+ * Control Register
+ */
+ u32 ectrstcr; /* 0x.0098 - Exception reset control register */
+ u32 autorstsr; /* 0x.009c - Automatic reset status register */
+ u32 pvr; /* 0x.00a0 - Processor Version Register */
+ u32 svr; /* 0x.00a4 - System Version Register */
u8 res0a8[0xb0 - 0xa8];
- __be32 rstcr; /* 0x.00b0 - Reset Control Register */
+ u32 rstcr; /* 0x.00b0 - Reset Control Register */
u8 res0b4[0xc0 - 0xb4];
- __be32 iovselsr; /* 0x.00c0 - I/O voltage select status register
+ u32 iovselsr; /* 0x.00c0 - I/O voltage select status register
Called 'elbcvselcr' on 86xx SOCs */
u8 res0c4[0x100 - 0xc4];
- __be32 rcwsr[16]; /* 0x.0100 - Reset Control Word Status registers
+ u32 rcwsr[16]; /* 0x.0100 - Reset Control Word Status registers
There are 16 registers */
u8 res140[0x224 - 0x140];
- __be32 iodelay1; /* 0x.0224 - IO delay control register 1 */
- __be32 iodelay2; /* 0x.0228 - IO delay control register 2 */
+ u32 iodelay1; /* 0x.0224 - IO delay control register 1 */
+ u32 iodelay2; /* 0x.0228 - IO delay control register 2 */
u8 res22c[0x604 - 0x22c];
- __be32 pamubypenr; /* 0x.604 - PAMU bypass enable register */
+ u32 pamubypenr; /* 0x.604 - PAMU bypass enable register */
u8 res608[0x800 - 0x608];
- __be32 clkdvdr; /* 0x.0800 - Clock Divide Register */
+ u32 clkdvdr; /* 0x.0800 - Clock Divide Register */
u8 res804[0x900 - 0x804];
- __be32 ircr; /* 0x.0900 - Infrared Control Register */
+ u32 ircr; /* 0x.0900 - Infrared Control Register */
u8 res904[0x908 - 0x904];
- __be32 dmacr; /* 0x.0908 - DMA Control Register */
+ u32 dmacr; /* 0x.0908 - DMA Control Register */
u8 res90c[0x914 - 0x90c];
- __be32 elbccr; /* 0x.0914 - eLBC Control Register */
+ u32 elbccr; /* 0x.0914 - eLBC Control Register */
u8 res918[0xb20 - 0x918];
- __be32 ddr1clkdr; /* 0x.0b20 - DDR1 Clock Disable Register */
- __be32 ddr2clkdr; /* 0x.0b24 - DDR2 Clock Disable Register */
- __be32 ddrclkdr; /* 0x.0b28 - DDR Clock Disable Register */
+ u32 ddr1clkdr; /* 0x.0b20 - DDR1 Clock Disable Register */
+ u32 ddr2clkdr; /* 0x.0b24 - DDR2 Clock Disable Register */
+ u32 ddrclkdr; /* 0x.0b28 - DDR Clock Disable Register */
u8 resb2c[0xe00 - 0xb2c];
- __be32 clkocr; /* 0x.0e00 - Clock Out Select Register */
+ u32 clkocr; /* 0x.0e00 - Clock Out Select Register */
u8 rese04[0xe10 - 0xe04];
- __be32 ddrdllcr; /* 0x.0e10 - DDR DLL Control Register */
+ u32 ddrdllcr; /* 0x.0e10 - DDR DLL Control Register */
u8 rese14[0xe20 - 0xe14];
- __be32 lbcdllcr; /* 0x.0e20 - LBC DLL Control Register */
- __be32 cpfor; /* 0x.0e24 - L2 charge pump fuse override register */
+ u32 lbcdllcr; /* 0x.0e20 - LBC DLL Control Register */
+ u32 cpfor; /* 0x.0e24 - L2 charge pump fuse override
+ * register
+ */
u8 rese28[0xf04 - 0xe28];
- __be32 srds1cr0; /* 0x.0f04 - SerDes1 Control Register 0 */
- __be32 srds1cr1; /* 0x.0f08 - SerDes1 Control Register 0 */
+ u32 srds1cr0; /* 0x.0f04 - SerDes1 Control Register 0 */
+ u32 srds1cr1; /* 0x.0f08 - SerDes1 Control Register 0 */
u8 resf0c[0xf2c - 0xf0c];
- __be32 itcr; /* 0x.0f2c - Internal transaction control register */
+ u32 itcr; /* 0x.0f2c - Internal transaction control
+ * register
+ */
u8 resf30[0xf40 - 0xf30];
- __be32 srds2cr0; /* 0x.0f40 - SerDes2 Control Register 0 */
- __be32 srds2cr1; /* 0x.0f44 - SerDes2 Control Register 0 */
+ u32 srds2cr0; /* 0x.0f40 - SerDes2 Control Register 0 */
+ u32 srds2cr1; /* 0x.0f44 - SerDes2 Control Register 0 */
} __attribute__ ((packed));
+u32 fsl_guts_get_svr(void);
/* Alternate function signal multiplex control */
#define MPC85xx_PMUXCR_QE(x) (0x8000 >> (x))
--
2.1.0.27.g96db324
^ permalink raw reply related
* [v12, 4/8] powerpc/fsl: move mpc85xx.h to include/linux/fsl
From: Yangbo Lu @ 2016-09-21 6:57 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Scott Wood, Arnd Bergmann
Cc: Mark Rutland, Xiaobo Xie, Minghuan Lian,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Qiang Zhao, Russell King,
Bhupesh Sharma, Jochen Friedrich, Claudiu Manoil,
devicetree-u79uwXL29TY76Z2rM5mHXA, Kumar Gala, Rob Herring,
Santosh Shilimkar,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Leo Li,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Yangbo Lu,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ
In-Reply-To: <1474441040-11946-1-git-send-email-yangbo.lu-3arQi8VN3Tc@public.gmane.org>
Move mpc85xx.h to include/linux/fsl and rename it to svr.h as a common
header file. This SVR numberspace is used on some ARM chips as well as
PPC, and even to check for a PPC SVR multi-arch drivers would otherwise
need to ifdef the header inclusion and all references to the SVR symbols.
Signed-off-by: Yangbo Lu <yangbo.lu-3arQi8VN3Tc@public.gmane.org>
Acked-by: Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>
Acked-by: Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Acked-by: Joerg Roedel <jroedel-l3A5Bk7waGM@public.gmane.org>
[scottwood: update description]
Signed-off-by: Scott Wood <oss-fOR+EgIDQEHk1uMJSBkQmQ@public.gmane.org>
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- None
Changes for v5:
- Changed to Move mpc85xx.h to include/linux/fsl/
- Adjusted '#include <linux/fsl/svr.h>' position in file
Changes for v6:
- None
Changes for v7:
- Added 'Acked-by: Wolfram Sang' for I2C part
- Also applied to arch/powerpc/kernel/cpu_setup_fsl_booke.S
Changes for v8:
- Added 'Acked-by: Stephen Boyd' for clk part
- Added 'Acked-by: Scott Wood'
- Added 'Acked-by: Joerg Roedel' for iommu part
Changes for v9:
- None
Changes for v10:
- None
Changes for v11:
- Updated description by Scott
Changes for v12:
- None
---
arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
arch/powerpc/sysdev/fsl_pci.c | 2 +-
drivers/clk/clk-qoriq.c | 3 +--
drivers/i2c/busses/i2c-mpc.c | 2 +-
drivers/iommu/fsl_pamu.c | 3 +--
drivers/net/ethernet/freescale/gianfar.c | 2 +-
arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h | 4 ++--
7 files changed, 8 insertions(+), 10 deletions(-)
rename arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h (97%)
diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
index 462aed9..2b0284e 100644
--- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
+++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
@@ -13,13 +13,13 @@
*
*/
+#include <linux/fsl/svr.h>
#include <asm/page.h>
#include <asm/processor.h>
#include <asm/cputable.h>
#include <asm/ppc_asm.h>
#include <asm/mmu-book3e.h>
#include <asm/asm-offsets.h>
-#include <asm/mpc85xx.h>
_GLOBAL(__e500_icache_setup)
mfspr r0, SPRN_L1CSR1
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 0ef9df4..0fd1895 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -22,6 +22,7 @@
#include <linux/delay.h>
#include <linux/string.h>
#include <linux/fsl/edac.h>
+#include <linux/fsl/svr.h>
#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/memblock.h>
@@ -37,7 +38,6 @@
#include <asm/pci-bridge.h>
#include <asm/ppc-pci.h>
#include <asm/machdep.h>
-#include <asm/mpc85xx.h>
#include <asm/disassemble.h>
#include <asm/ppc-opcode.h>
#include <sysdev/fsl_soc.h>
diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c
index 58566a17..4b6c438 100644
--- a/drivers/clk/clk-qoriq.c
+++ b/drivers/clk/clk-qoriq.c
@@ -13,6 +13,7 @@
#include <linux/clk.h>
#include <linux/clk-provider.h>
#include <linux/fsl/guts.h>
+#include <linux/fsl/svr.h>
#include <linux/io.h>
#include <linux/kernel.h>
#include <linux/module.h>
@@ -1149,8 +1150,6 @@ bad_args:
}
#ifdef CONFIG_PPC
-#include <asm/mpc85xx.h>
-
static const u32 a4510_svrs[] __initconst = {
(SVR_P2040 << 8) | 0x10, /* P2040 1.0 */
(SVR_P2040 << 8) | 0x11, /* P2040 1.1 */
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 48ecffe..600704c 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -27,9 +27,9 @@
#include <linux/i2c.h>
#include <linux/interrupt.h>
#include <linux/delay.h>
+#include <linux/fsl/svr.h>
#include <asm/mpc52xx.h>
-#include <asm/mpc85xx.h>
#include <sysdev/fsl_soc.h>
#define DRV_NAME "mpc-i2c"
diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
index a34355f..af8fb27 100644
--- a/drivers/iommu/fsl_pamu.c
+++ b/drivers/iommu/fsl_pamu.c
@@ -21,11 +21,10 @@
#include "fsl_pamu.h"
#include <linux/fsl/guts.h>
+#include <linux/fsl/svr.h>
#include <linux/interrupt.h>
#include <linux/genalloc.h>
-#include <asm/mpc85xx.h>
-
/* define indexes for each operation mapping scenario */
#define OMI_QMAN 0x00
#define OMI_FMAN 0x01
diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index 4b4f5bc..55be5ce 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -86,11 +86,11 @@
#include <linux/udp.h>
#include <linux/in.h>
#include <linux/net_tstamp.h>
+#include <linux/fsl/svr.h>
#include <asm/io.h>
#ifdef CONFIG_PPC
#include <asm/reg.h>
-#include <asm/mpc85xx.h>
#endif
#include <asm/irq.h>
#include <asm/uaccess.h>
diff --git a/arch/powerpc/include/asm/mpc85xx.h b/include/linux/fsl/svr.h
similarity index 97%
rename from arch/powerpc/include/asm/mpc85xx.h
rename to include/linux/fsl/svr.h
index 213f3a8..8d13836 100644
--- a/arch/powerpc/include/asm/mpc85xx.h
+++ b/include/linux/fsl/svr.h
@@ -9,8 +9,8 @@
* (at your option) any later version.
*/
-#ifndef __ASM_PPC_MPC85XX_H
-#define __ASM_PPC_MPC85XX_H
+#ifndef FSL_SVR_H
+#define FSL_SVR_H
#define SVR_REV(svr) ((svr) & 0xFF) /* SOC design resision */
#define SVR_MAJ(svr) (((svr) >> 4) & 0xF) /* Major revision field*/
--
2.1.0.27.g96db324
^ permalink raw reply related
* [v12, 3/8] dt: bindings: move guts devicetree doc out of powerpc directory
From: Yangbo Lu @ 2016-09-21 6:57 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Scott Wood, Arnd Bergmann
Cc: Mark Rutland, Xiaobo Xie, Minghuan Lian,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Qiang Zhao, Russell King,
Bhupesh Sharma, Jochen Friedrich, Claudiu Manoil,
devicetree-u79uwXL29TY76Z2rM5mHXA, Kumar Gala, Rob Herring,
Santosh Shilimkar,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Leo Li,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Yangbo Lu,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ
In-Reply-To: <1474441040-11946-1-git-send-email-yangbo.lu-3arQi8VN3Tc@public.gmane.org>
Move guts devicetree doc to Documentation/devicetree/bindings/soc/fsl/
since it's used by not only PowerPC but also ARM. And add a specification
for 'little-endian' property.
Signed-off-by: Yangbo Lu <yangbo.lu-3arQi8VN3Tc@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Acked-by: Scott Wood <oss-fOR+EgIDQEHk1uMJSBkQmQ@public.gmane.org>
---
Changes for v4:
- Added this patch
Changes for v5:
- Modified the description for little-endian property
Changes for v6:
- None
Changes for v7:
- None
Changes for v8:
- Added 'Acked-by: Scott Wood'
- Added 'Acked-by: Rob Herring'
Changes for v9:
- None
Changes for v10:
- None
Changes for v11:
- None
Changes for v12:
- None
---
Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt | 3 +++
1 file changed, 3 insertions(+)
rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt b/Documentation/devicetree/bindings/soc/fsl/guts.txt
similarity index 91%
rename from Documentation/devicetree/bindings/powerpc/fsl/guts.txt
rename to Documentation/devicetree/bindings/soc/fsl/guts.txt
index b71b203..07adca9 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
+++ b/Documentation/devicetree/bindings/soc/fsl/guts.txt
@@ -25,6 +25,9 @@ Recommended properties:
- fsl,liodn-bits : Indicates the number of defined bits in the LIODN
registers, for those SOCs that have a PAMU device.
+ - little-endian : Indicates that the global utilities block is little
+ endian. The default is big endian.
+
Examples:
global-utilities@e0000 { /* global utilities block */
compatible = "fsl,mpc8548-guts";
--
2.1.0.27.g96db324
^ permalink raw reply related
* [v12, 2/8] ARM64: dts: ls2080a: add device configuration node
From: Yangbo Lu @ 2016-09-21 6:57 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Scott Wood, Arnd Bergmann
Cc: Mark Rutland, Xiaobo Xie, Minghuan Lian,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Qiang Zhao, Russell King,
Bhupesh Sharma, Jochen Friedrich, Claudiu Manoil,
devicetree-u79uwXL29TY76Z2rM5mHXA, Kumar Gala, Rob Herring,
Santosh Shilimkar,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Leo Li,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Yangbo Lu,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ
In-Reply-To: <1474441040-11946-1-git-send-email-yangbo.lu-3arQi8VN3Tc@public.gmane.org>
Add the dts node for device configuration unit that provides
general purpose configuration and status for the device.
Signed-off-by: Yangbo Lu <yangbo.lu-3arQi8VN3Tc@public.gmane.org>
Acked-by: Scott Wood <oss-fOR+EgIDQEHk1uMJSBkQmQ@public.gmane.org>
---
Changes for v5:
- Added this patch
Changes for v6:
- None
Changes for v7:
- None
Changes for v8:
- Added 'Acked-by: Scott Wood'
Changes for v9:
- None
Changes for v10:
- None
Changes for v11:
- None
Changes for v12:
- None
---
arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
index e3b6034..f231a14 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
@@ -215,6 +215,12 @@
clocks = <&sysclk>;
};
+ dcfg: dcfg@1e00000 {
+ compatible = "fsl,ls2080a-dcfg", "syscon";
+ reg = <0x0 0x1e00000 0x0 0x10000>;
+ little-endian;
+ };
+
serial0: serial@21c0500 {
compatible = "fsl,ns16550", "ns16550a";
reg = <0x0 0x21c0500 0x0 0x100>;
--
2.1.0.27.g96db324
^ permalink raw reply related
* [v12, 1/8] dt: bindings: update Freescale DCFG compatible
From: Yangbo Lu @ 2016-09-21 6:57 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Scott Wood, Arnd Bergmann
Cc: Mark Rutland, Xiaobo Xie, Minghuan Lian,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Qiang Zhao, Russell King,
Bhupesh Sharma, Jochen Friedrich, Claudiu Manoil,
devicetree-u79uwXL29TY76Z2rM5mHXA, Kumar Gala, Rob Herring,
Santosh Shilimkar,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Leo Li,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Yangbo Lu,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ
In-Reply-To: <1474441040-11946-1-git-send-email-yangbo.lu-3arQi8VN3Tc@public.gmane.org>
Update Freescale DCFG compatible with 'fsl,<chip>-dcfg' instead
of 'fsl,ls1021a-dcfg' to include more chips such as ls1021a,
ls1043a, and ls2080a.
Signed-off-by: Yangbo Lu <yangbo.lu-3arQi8VN3Tc@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Scott Wood <oss-fOR+EgIDQEHk1uMJSBkQmQ@public.gmane.org>
---
Changes for v8:
- Added this patch
Changes for v9:
- Added a list for the possible compatibles
Changes for v10:
- None
Changes for v11:
- Added 'Acked-by: Rob Herring'
- Updated commit message by Scott
Changes for v12:
- None
---
Documentation/devicetree/bindings/arm/fsl.txt | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt
index dbbc095..713c1ae 100644
--- a/Documentation/devicetree/bindings/arm/fsl.txt
+++ b/Documentation/devicetree/bindings/arm/fsl.txt
@@ -119,7 +119,11 @@ Freescale DCFG
configuration and status for the device. Such as setting the secondary
core start address and release the secondary core from holdoff and startup.
Required properties:
- - compatible: should be "fsl,ls1021a-dcfg"
+ - compatible: should be "fsl,<chip>-dcfg"
+ Possible compatibles:
+ "fsl,ls1021a-dcfg"
+ "fsl,ls1043a-dcfg"
+ "fsl,ls2080a-dcfg"
- reg : should contain base address and length of DCFG memory-mapped registers
Example:
--
2.1.0.27.g96db324
^ permalink raw reply related
* [v12, 0/8] Fix eSDHC host version register bug
From: Yangbo Lu @ 2016-09-21 6:57 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Scott Wood, Arnd Bergmann
Cc: Mark Rutland, Xiaobo Xie, Minghuan Lian,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Qiang Zhao, Russell King,
Bhupesh Sharma, Jochen Friedrich, Claudiu Manoil,
devicetree-u79uwXL29TY76Z2rM5mHXA, Kumar Gala, Rob Herring,
Santosh Shilimkar,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Leo Li,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Yangbo Lu,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ
This patchset is used to fix a host version register bug in the T4240-R1.0-R2.0
eSDHC controller. To match the SoC version and revision, 10 previous version
patchsets had tried many methods but all of them were rejected by reviewers.
Such as
- dts compatible method
- syscon method
- ifdef PPC method
- GUTS driver getting SVR method
Anrd suggested a soc_device_match method in v10, and this is the only available
method left now. This v11 patchset introduces the soc_device_match interface in
soc driver.
The first six patches of Yangbo are to add the GUTS driver. This is used to
register a soc device which contain soc version and revision information.
The other two patches introduce the soc_device_match method in soc driver
and apply it on esdhc driver to fix this bug.
Arnd Bergmann (1):
base: soc: introduce soc_device_match() interface
Yangbo Lu (7):
dt: bindings: update Freescale DCFG compatible
ARM64: dts: ls2080a: add device configuration node
dt: bindings: move guts devicetree doc out of powerpc directory
powerpc/fsl: move mpc85xx.h to include/linux/fsl
soc: fsl: add GUTS driver for QorIQ platforms
MAINTAINERS: add entry for Freescale SoC drivers
mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
Documentation/devicetree/bindings/arm/fsl.txt | 6 +-
.../bindings/{powerpc => soc}/fsl/guts.txt | 3 +
MAINTAINERS | 11 +-
arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 +
arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
arch/powerpc/sysdev/fsl_pci.c | 2 +-
drivers/base/Kconfig | 1 +
drivers/base/soc.c | 66 ++++++
drivers/clk/clk-qoriq.c | 3 +-
drivers/i2c/busses/i2c-mpc.c | 2 +-
drivers/iommu/fsl_pamu.c | 3 +-
drivers/mmc/host/Kconfig | 1 +
drivers/mmc/host/sdhci-of-esdhc.c | 20 ++
drivers/net/ethernet/freescale/gianfar.c | 2 +-
drivers/soc/Kconfig | 2 +-
drivers/soc/fsl/Kconfig | 19 ++
drivers/soc/fsl/Makefile | 1 +
drivers/soc/fsl/guts.c | 257 +++++++++++++++++++++
include/linux/fsl/guts.h | 125 ++++++----
.../asm/mpc85xx.h => include/linux/fsl/svr.h | 4 +-
include/linux/sys_soc.h | 3 +
21 files changed, 478 insertions(+), 61 deletions(-)
rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
create mode 100644 drivers/soc/fsl/Kconfig
create mode 100644 drivers/soc/fsl/guts.c
rename arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h (97%)
--
2.1.0.27.g96db324
^ permalink raw reply
* Re: [net-next 02/15] i40e: Enable VF specific ethtool statistics via VF Port representor netdevs
From: Or Gerlitz @ 2016-09-21 6:54 UTC (permalink / raw)
To: Samudrala, Sridhar
Cc: Jeff Kirsher, David Miller, Linux Netdev List, nhorman@redhat.com,
sassmann@redhat.com, jogreene@redhat.com, guru.anbalagane
In-Reply-To: <57E221B3.2000004@intel.com>
On Wed, Sep 21, 2016 at 8:59 AM, Samudrala, Sridhar
<sridhar.samudrala@intel.com> wrote:
> On 9/20/2016 9:26 PM, Or Gerlitz wrote:
>> Now, when the SW stats are finally upstream for 4.9 in net-next, the
>> correct approach
>> for the VF reps counters is to follow the architecture presented there
>> [1] -- and this is
>> for the netlink based standard counters. Once you do that, there's no
>> need to expose
>> the VF HW counters through ethtool of the VF rep.
> Sure. Will look into it. However, i think we can keep ethtool support also
> as VFPR represents the switch port corresponding to the VF.
Exactly b/c the VFPR represented the VF switch port, their "normal" stats
is what you are exposing here through ethtool, you can just drop this and
move to the strategy introduced in Nogah's work. Once you support TX/RX
on the VFPRs you can also add the SW stats she added too.
^ permalink raw reply
* Re: [PATCH RFC 1/3] xdp: Infrastructure to generalize XDP
From: Jesper Dangaard Brouer @ 2016-09-21 6:39 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Tom Herbert, davem, netdev, kernel-team, tariqt, bblanco,
alexei.starovoitov, eric.dumazet, brouer
In-Reply-To: <57E1CDE3.5030404@fb.com>
On Tue, 20 Sep 2016 17:01:39 -0700 Alexei Starovoitov <ast@fb.com> wrote:
> > - Provides a more structured environment that is extensible to new
> > features while being mostly transparent to the drivers
>
> don't see that in these patches either.
> Things like packet size change (that we're working on) still
> has to be implemented for every driver.
> Existing XDP_TX, XDP_DROP have to be implemented per driver as well.
>
> Also introduction of xdp.h breaks existing UAPI.
> That's not acceptable either.
This response piss me off!@@#$
We are the early stages of XDP development. Users cannot consider XDP a
stable UAPI yet. I added a big fat warning to the docs here[1].
If you already consider this a stable API, then I will suggest that we
disable XDP or rip the hole thing out again!!! Create a separate tree
where we can cooperate on getting this right, before forcing this
upstream. I have raise concern about this several times upstream, but
the patches got applied anyway, because you Alexei, promised this was
super extendable and we could still change the APIs later. Maybe you
tricked me?! I've started to look at the details, and I'm not happy with
the extensibility. And I'm also not happy with Brenden's response to
my API concerns that this is just a "fire-and-forget" API.
Most importantly, the XDP interface for feature or capabilities
negotiation is missing. Documented here[2].
I strongly believe the two actions XDP_DROP and XDP_TX should have been
express as two different capabilities, because XDP_TX requires more
changes to the device driver than a simple drop like XDP_DROP.
One can easily imagine (after the e1000 discussion) that an older
driver only want to implement the XDP_DROP facility. The reason is that
XDP_TX would requires changing too much driver code, which is a concern
for an old stable and time-proven driver. Thus, the need for
negotiating features is already a practical problem!
[1] https://prototype-kernel.readthedocs.io/en/latest/networking/XDP/implementation/userspace_api.html
Quote:
"Warning: The userspace API specification should have to be defined
properly before code was accepted upstream. Concerns have been raise
about the current API upstream. Users should expect this first API
attempt will need adjustments. This cannot be considered a stable API yet."
[2] https://prototype-kernel.readthedocs.io/en/latest/networking/XDP/design/design.html#capabilities-negotiation
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* [PATCH] brcmfmac: fix memory leak in brcmf_fill_bss_param
From: Rafał Miłecki @ 2016-09-21 6:23 UTC (permalink / raw)
To: Kalle Valo
Cc: Rafał Miłecki, Arend van Spriel, Franky Lin,
Hante Meuleman, Pieter-Paul Giesberts, Franky (Zhenhui) Lin,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
open list:NETWORKING DRIVERS, open list
From: Rafał Miłecki <rafal@milecki.pl>
This function is called from get_station callback which means that every
time user space was getting/dumping station(s) we were leaking 2 KiB.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Fixes: 1f0dc59a6de ("brcmfmac: rework .get_station() callback")
Cc: stable@vger.kernel.org # 4.2+
---
Kalle, ideally this should go as 4.8 fix, but I'm aware it's quite late.
If you are not planning to send another pull request, just get it for
the next release and let's let stable guys backport it.
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index b8aec5e5..62a7675 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -2533,7 +2533,7 @@ static void brcmf_fill_bss_param(struct brcmf_if *ifp, struct station_info *si)
WL_BSS_INFO_MAX);
if (err) {
brcmf_err("Failed to get bss info (%d)\n", err);
- return;
+ goto out_kfree;
}
si->filled |= BIT(NL80211_STA_INFO_BSS_PARAM);
si->bss_param.beacon_interval = le16_to_cpu(buf->bss_le.beacon_period);
@@ -2545,6 +2545,9 @@ static void brcmf_fill_bss_param(struct brcmf_if *ifp, struct station_info *si)
si->bss_param.flags |= BSS_PARAM_FLAGS_SHORT_PREAMBLE;
if (capability & WLAN_CAPABILITY_SHORT_SLOT_TIME)
si->bss_param.flags |= BSS_PARAM_FLAGS_SHORT_SLOT_TIME;
+
+out_kfree:
+ kfree(buf);
}
static s32
--
2.9.3
^ permalink raw reply related
* Re: [PATCH net-next 3/3] net: ethernet: mediatek: add the dts property to set if TRGMII supported on GMAC0
From: Sean Wang @ 2016-09-21 6:16 UTC (permalink / raw)
To: andrew; +Cc: john, davem, nbd, netdev, linux-mediatek, keyhaede
In-Reply-To: <1474358360-29901-4-git-send-email-sean.wang@mediatek.com>
Date: Tue, 20 Sep 2016 21:37:58 +0200, Andrew Lunn <andrew@lunn.ch> wrote:
>On Tue, Sep 20, 2016 at 03:59:20PM +0800, sean.wang@mediatek.com wrote:
>> From: Sean Wang <sean.wang@mediatek.com>
>>
>> Add the dts property for the capability if TRGMII supported on GAMC0
>>
>> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
>> ---
>> Documentation/devicetree/bindings/net/mediatek-net.txt | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt b/Documentation/devicetree/bindings/net/mediatek-net.txt
>> index 6103e55..32f79d8 100644
>> --- a/Documentation/devicetree/bindings/net/mediatek-net.txt
>> +++ b/Documentation/devicetree/bindings/net/mediatek-net.txt
>> @@ -31,7 +31,10 @@ Optional properties:
>> Required properties:
>> - compatible: Should be "mediatek,eth-mac"
>> - reg: The number of the MAC
>> -- phy-handle: see ethernet.txt file in the same directory.
>> +- phy-handle: see ethernet.txt file in the same directory and
>> + the additional phy-mode "tgrmii" is provided in order to connect
>> + with the internal switch MT7530 which is only applicable when reg
>> + is equal to 0.
>
>Humm. How is the switch connected? Is it on the MDIO bus?
the switch is connected to MDIO bus
>If it is on the mdio bus, the binding is going to look something like:
>
>eth: ethernet@1b100000 {
> compatible = "mediatek,mt7623-eth";
> reg = <0 0x1b100000 0 0x20000>;
> clocks = <&topckgen CLK_TOP_ETHIF_SEL>,
> <ðsys CLK_ETHSYS_ESW>,
> <ðsys CLK_ETHSYS_GP2>,
> <ðsys CLK_ETHSYS_GP1>;
> clock-names = "ethif", "esw", "gp2", "gp1";
> interrupts = <GIC_SPI 200 IRQ_TYPE_LEVEL_LOW
> GIC_SPI 199 IRQ_TYPE_LEVEL_LOW
> GIC_SPI 198 IRQ_TYPE_LEVEL_LOW>;
> power-domains = <&scpsys MT2701_POWER_DOMAIN_ETH>;
> resets = <ðsys MT2701_ETHSYS_ETH_RST>;
> reset-names = "eth";
> mediatek,ethsys = <ðsys>;
> mediatek,pctl = <&syscfg_pctl_a>;
> #address-cells = <1>;
> #size-cells = <0>;
>
> gmac1: mac@0 {
> compatible = "mediatek,eth-mac";
> reg = <0>;
> };
>
> gmac2: mac@1 {
> compatible = "mediatek,eth-mac";
> reg = <1>;
> };
>
> mdio-bus {
> reg = <1>;
> #address-cells = <1>;
> #size-cells = <0>;
>
> switch0: switch0@0 {
> compatible = "marvell,mv88e6085";
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <0>;
> dsa,member = <0 0>;
>
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> port@0 {
> reg = <0>;
> label = "lan0";
>...
>...
>In this case the switch is an MDIO device, not an PHY. It will not
>have an phy-mode. It cannot have a phy mode, it is not a PHY.
>
>Or am i missing something here?
>
>Thanks
>
1)
The switch driver is not supported for DSA so far yet
but DSA is good thing and I will try make it happen
in the near future.
And another question about DSA, that is
if I use DSA for switch, how to know the relationship
between MAC and DSA ? such like I could know relationship
between MAC and PHY by phy-handle.
The cause I ask is becasue I think it's good if the topology
about MAC/PHYs/Switch is known just by dts files.
2)
The phy-mode I mention is for fixed-link. For current MAC driver,
it just uses fixed phy to adapt into the part of switch, so the
device tree looks something like the below.
ð {
status = "okay";
gmac0: mac@0 {
compatible = "mediatek,eth-mac";
reg = <0>;
phy-mode = "trgmii";
fixed-link {
speed = <1000>;
full-duplex;
pause;
};
};
gmac1: mac@1 {
compatible = "mediatek,eth-mac";
reg = <1>;
phy-handle = <&phy5>;
};
^ permalink raw reply
* Re: [RFC] PCI: Allow sysfs control over totalvfs
From: Mintz, Yuval @ 2016-09-21 6:00 UTC (permalink / raw)
To: Jiri Pirko
Cc: Yuval Mintz, linux-pci@vger.kernel.org, netdev@vger.kernel.org,
Chickles, Derek
In-Reply-To: <20160921055527.GB2078@nanopsycho.orion>
> >> One of the motivations for introducing devlink interface was to allow
> >> user to pass some kind of well defined option parameters or as you call
> >> it hints to driver module. That would allow to replace module options
> >> and introduce similar possibility to pre-configure hardware on probe time.
> >> We plan to use devlink to allow user to change resource allocation for
> >> mlxsw devices.
> > >
> >Is IOV configuration something you're going to explore in the near
> >future for mlxsw devices? Or are you merely pointing out that
> No, not sriov related directly.
> >devlink could provide a superior configuration infrastrucutre and
> >should be investigated as a better alternative?
> Exactly. It is a general problem of how to pre-configure driver modules.
> >> The plan is to allow to pre-create devlink instance before driver module
> >> is loaded. Then the user will use this placeholder to do the options
> >> setting. Once the driver module is loaded, it will fetch the options
> >> from devlink core and process it accordingly.
> >
> >> I believe this is exactly what you need.
> Adding devlink support is trivial in most cases, I bet you can do it in
> couple of minutes for your driver.
I'll go and educate myself, then.
Thanks.
^ permalink raw reply
* Re: [net-next 02/15] i40e: Enable VF specific ethtool statistics via VF Port representor netdevs
From: Samudrala, Sridhar @ 2016-09-21 5:59 UTC (permalink / raw)
To: Or Gerlitz, Jeff Kirsher
Cc: David Miller, Linux Netdev List, nhorman@redhat.com,
sassmann@redhat.com, jogreene@redhat.com, guru.anbalagane
In-Reply-To: <CAJ3xEMhM63HxyQxv3YyN7Lb3uCOWsA3aqfkhnuzdJqtNRty8Zw@mail.gmail.com>
On 9/20/2016 9:26 PM, Or Gerlitz wrote:
> On Wed, Sep 21, 2016 at 6:43 AM, Jeff Kirsher
> <jeffrey.t.kirsher@intel.com> wrote:
>> From: Sridhar Samudrala <sridhar.samudrala@intel.com>
>>
>> Sample script that shows ethtool stats on VF representor netdev
>> PF: enp5s0f0, VF0: enp5s2 VF_REP0: enp5s0f0-vf0
>>
>> # echo 2 > /sys/class/net/enp5s0f0/device/sriov_numvfs
>> # ip link set enp5s2 up
>> # ethtool -S enp5s0f0-vf0
>> NIC statistics:
>> tx_bytes: 0
>> tx_unicast: 0
>> tx_multicast: 0
>> tx_broadcast: 0
>> tx_discards: 0
>> tx_errors: 0
>> rx_bytes: 140
>> rx_unicast: 0
>> rx_multicast: 2
>> rx_broadcast: 0
>> rx_discards: 0
>> rx_unknown_protocol: 0
> Now, when the SW stats are finally upstream for 4.9 in net-next, the
> correct approach
> for the VF reps counters is to follow the architecture presented there
> [1] -- and this is
> for the netlink based standard counters. Once you do that, there's no
> need to expose
> the VF HW counters through ethtool of the VF rep.
Sure. Will look into it. However, i think we can keep ethtool support
also as VFPR
represents the switch port corresponding to the VF.
>
> Or.
>
>
> [1] offloaded stats commits
> a5ea31f Merge branch 'net-offloaded-stats'
> fc1bbb0 mlxsw: spectrum: Implement offload stats ndo and expose HW
> stats by default
> 69ae6ad net: core: Add offload stats to if_stats_msg
> 2c9d85d netdevice: Add offload statistics ndo
^ permalink raw reply
* Re: [RFC] PCI: Allow sysfs control over totalvfs
From: Jiri Pirko @ 2016-09-21 5:55 UTC (permalink / raw)
To: Mintz, Yuval
Cc: Yuval Mintz, linux-pci@vger.kernel.org, netdev@vger.kernel.org,
Chickles, Derek
In-Reply-To: <BL2PR07MB23061E60A3ABC771F05764C98DF70@BL2PR07MB2306.namprd07.prod.outlook.com>
Tue, Sep 20, 2016 at 10:27:24PM CEST, Yuval.Mintz@cavium.com wrote:
>> >Some of the HW capable of SRIOV has resource limitations, where the
>> >PF and VFs resources are drawn from a common pool.
>> >In some cases, these limitations have to be considered early during
>> >chip initialization and can only be changed by tearing down the
>> >configuration and re-initializing.
>> >As a result, drivers for such HWs sometimes have to make unfavorable
>> >compromises where they reserve sufficient resources to accomadate
>> >the maximal number of VFs that can be created - at the expanse of
>> >resources that could have been used by the PF.
>> >
>> >If users were able to provide 'hints' regarding the required number
>> >of VFs *prior* to driver attachment, then such compromises could be
>> >avoided. As we already have sysfs nodes that can be queried for the
>> >number of totalvfs, it makes sense to let the user reduce the number
>> >of said totalvfs using same infrastrucure.
>> >Then, we can have drivers supporting SRIOV take that value into account
>> >when deciding how much resources to reserve, allowing the PF to benefit
>> >from the difference between the configuration space value and the actual
>> >number needed by user.
>
>> One of the motivations for introducing devlink interface was to allow
>> user to pass some kind of well defined option parameters or as you call
>> it hints to driver module. That would allow to replace module options
>> and introduce similar possibility to pre-configure hardware on probe time.
>> We plan to use devlink to allow user to change resource allocation for
>> mlxsw devices.
>
>Is IOV configuration something you're going to explore in the near
>future for mlxsw devices? Or are you merely pointing out that
No, not sriov related directly.
>devlink could provide a superior configuration infrastrucutre and
>should be investigated as a better alternative?
Exactly. It is a general problem of how to pre-configure driver modules.
>
>> The plan is to allow to pre-create devlink instance before driver module
>> is loaded. Then the user will use this placeholder to do the options
>> setting. Once the driver module is loaded, it will fetch the options
>> from devlink core and process it accordingly.
>
>> I believe this is exactly what you need.
>
>While this sounds far-superior to anything we can do via pci sysfs,
>question is whether adding a devlink support for a device is
>a reasonable cost for adding this specific configuration [given
>the existing sysfs nodes we already have].
Adding devlink support is trivial in most cases, I bet you can do it in
couple of minutes for your driver.
>I'm not sufficiently familiar with the infrastrucutre there, and I
>wonder whether it will set the bar too high for this sort of
>configuration to be used.
^ permalink raw reply
* [PATCH net-next] tcp: implement TSQ for retransmits
From: Eric Dumazet @ 2016-09-21 5:45 UTC (permalink / raw)
To: David Miller; +Cc: Neal Cardwell, Yuchung Cheng, netdev
In-Reply-To: <1474424880.23058.65.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <edumazet@google.com>
We saw sch_fq drops caused by the per flow limit of 100 packets and TCP
when dealing with large cwnd and bursts of retransmits.
Even after increasing the limit to 1000, and even after commit
10d3be569243 ("tcp-tso: do not split TSO packets at retransmit time"),
we can still have these drops.
Under certain conditions, TCP can spend a considerable amount of
time queuing thousands of skbs in a single tcp_xmit_retransmit_queue()
invocation, incurring latency spikes and stalls of other softirq
handlers.
This patch implements TSQ for retransmits, limiting number of packets
and giving more chance for scheduling packets in both ways.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
---
net/ipv4/tcp_output.c | 72 ++++++++++++++++++++++++++--------------
1 file changed, 47 insertions(+), 25 deletions(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 7d025a7804b597465564f0980f2ac069d6c61d27..478dfc53917815d30838a21b1adc2ea7096425af 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -734,9 +734,16 @@ static void tcp_tsq_handler(struct sock *sk)
{
if ((1 << sk->sk_state) &
(TCPF_ESTABLISHED | TCPF_FIN_WAIT1 | TCPF_CLOSING |
- TCPF_CLOSE_WAIT | TCPF_LAST_ACK))
- tcp_write_xmit(sk, tcp_current_mss(sk), tcp_sk(sk)->nonagle,
+ TCPF_CLOSE_WAIT | TCPF_LAST_ACK)) {
+ struct tcp_sock *tp = tcp_sk(sk);
+
+ if (tp->lost_out > tp->retrans_out &&
+ tp->snd_cwnd > tcp_packets_in_flight(tp))
+ tcp_xmit_retransmit_queue(sk);
+
+ tcp_write_xmit(sk, tcp_current_mss(sk), tp->nonagle,
0, GFP_ATOMIC);
+ }
}
/*
* One tasklet per cpu tries to send more skbs.
@@ -2039,6 +2046,39 @@ static int tcp_mtu_probe(struct sock *sk)
return -1;
}
+/* TCP Small Queues :
+ * Control number of packets in qdisc/devices to two packets / or ~1 ms.
+ * (These limits are doubled for retransmits)
+ * This allows for :
+ * - better RTT estimation and ACK scheduling
+ * - faster recovery
+ * - high rates
+ * Alas, some drivers / subsystems require a fair amount
+ * of queued bytes to ensure line rate.
+ * One example is wifi aggregation (802.11 AMPDU)
+ */
+static bool tcp_small_queue_check(struct sock *sk, const struct sk_buff *skb,
+ unsigned int factor)
+{
+ unsigned int limit;
+
+ limit = max(2 * skb->truesize, sk->sk_pacing_rate >> 10);
+ limit = min_t(u32, limit, sysctl_tcp_limit_output_bytes);
+ limit <<= factor;
+
+ if (atomic_read(&sk->sk_wmem_alloc) > limit) {
+ set_bit(TSQ_THROTTLED, &tcp_sk(sk)->tsq_flags);
+ /* It is possible TX completion already happened
+ * before we set TSQ_THROTTLED, so we must
+ * test again the condition.
+ */
+ smp_mb__after_atomic();
+ if (atomic_read(&sk->sk_wmem_alloc) > limit)
+ return true;
+ }
+ return false;
+}
+
/* This routine writes packets to the network. It advances the
* send_head. This happens as incoming acks open up the remote
* window for us.
@@ -2125,29 +2165,8 @@ static bool tcp_write_xmit(struct sock *sk, unsigned int mss_now, int nonagle,
unlikely(tso_fragment(sk, skb, limit, mss_now, gfp)))
break;
- /* TCP Small Queues :
- * Control number of packets in qdisc/devices to two packets / or ~1 ms.
- * This allows for :
- * - better RTT estimation and ACK scheduling
- * - faster recovery
- * - high rates
- * Alas, some drivers / subsystems require a fair amount
- * of queued bytes to ensure line rate.
- * One example is wifi aggregation (802.11 AMPDU)
- */
- limit = max(2 * skb->truesize, sk->sk_pacing_rate >> 10);
- limit = min_t(u32, limit, sysctl_tcp_limit_output_bytes);
-
- if (atomic_read(&sk->sk_wmem_alloc) > limit) {
- set_bit(TSQ_THROTTLED, &tp->tsq_flags);
- /* It is possible TX completion already happened
- * before we set TSQ_THROTTLED, so we must
- * test again the condition.
- */
- smp_mb__after_atomic();
- if (atomic_read(&sk->sk_wmem_alloc) > limit)
- break;
- }
+ if (tcp_small_queue_check(sk, skb, 0))
+ break;
if (unlikely(tcp_transmit_skb(sk, skb, 1, gfp)))
break;
@@ -2847,6 +2866,9 @@ begin_fwd:
if (sacked & (TCPCB_SACKED_ACKED|TCPCB_SACKED_RETRANS))
continue;
+ if (tcp_small_queue_check(sk, skb, 1))
+ return;
+
if (tcp_retransmit_skb(sk, skb, segs))
return;
^ permalink raw reply related
* Re: [net-next 01/15] i40e: Introduce VF port representor/control netdevs
From: Samudrala, Sridhar @ 2016-09-21 5:45 UTC (permalink / raw)
To: Or Gerlitz, Jeff Kirsher
Cc: David Miller, Linux Netdev List, nhorman@redhat.com,
sassmann@redhat.com, jogreene@redhat.com, guru.anbalagane,
Ilya Lesokhin, Andy Gospodarek, John Fastabend, Jiri Pirko,
Rony Efraim
In-Reply-To: <CAJ3xEMhtyrS_jKrZ8UYWDi-UjK4RuxbwUSs8H=nFqWrTgzDVdw@mail.gmail.com>
On 9/20/2016 9:22 PM, Or Gerlitz wrote:
> On Wed, Sep 21, 2016 at 6:43 AM, Jeff Kirsher
> <jeffrey.t.kirsher@intel.com> wrote:
>> From: Sridhar Samudrala <sridhar.samudrala@intel.com>
>> This patch enables creation of a VF Port representor/Control netdev
>> associated with each VF. These netdevs can be used to control and configure
>> VFs from PFs namespace. They enable exposing VF statistics, configuring
>> link state, mtu, fdb/vlan entries etc.
> What happens if someone does a xmit on the VF representor, does the
> packet show up @ the VF?
> and what happens of the VF xmits and there's no HW steering rule that
> matches this, does
> the frame show up @ the VF rep on the host?
TX/RX are not yet supported via VFPR netdevs in this patch series.
Will be submitting this support in the next patchset.
>
> In other words, can these VF reps serve for setting up host SW based
> switching which you
> can later offload (through TC, bridge, netfilter, etc)?
Yes. These offloads will be possible via VFPRs.
>
> I am posing these questions because in downstream patch you are adding
> devlink support
> for set/get the e-switch mode and you declare the default mode to be switchdev.
>
> When the switchdev mode was introduced in 4.8 these RX/TX
> characteristics were defined
> to be an essential (== requirement) part for a driver to support that mode.
The current patchset introduces the basic VFPR support starting with
exposing VF stats and
syncing link state between VFs and VFPRs.
We decided to declare the default mode to be switchdev so that the new
code paths will get
exercised by default during normal testing.
>
> Or
>
>> # echo 2 > /sys/class/net/enp5s0f0/device/sriov_numvfs
>> # ip l show
>> 297: enp5s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop portid 6805ca2e7268 state DOWN mode DEFAULT group default qlen 1000
>> link/ether 68:05:ca:2e:72:68 brd ff:ff:ff:ff:ff:ff
>> vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state auto, trust off
>> vf 1 MAC 00:00:00:00:00:00, spoof checking on, link-state auto, trust off
>> 299: enp5s0f0-vf0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
>> link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
>> 300: enp5s0f0-vf1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
>> link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
^ permalink raw reply
* Re: [patch net-next 0/9] mlxsw: Replace Hw related const with resource query results
From: David Miller @ 2016-09-21 5:02 UTC (permalink / raw)
To: jiri; +Cc: netdev, nogahf, idosch, eladr, yotamg, ogerlitz
In-Reply-To: <1474363017-2901-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Tue, 20 Sep 2016 11:16:48 +0200
> Many of the ASIC's properties can be read from the HW with resources query.
> This patchset adds new resources to the resource query and implement
> using them, instead of the constants that we currently use.
> Those resources are lag, kvd and router related.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net v2] ipmr, ip6mr: return lastuse relative to now
From: David Miller @ 2016-09-21 4:58 UTC (permalink / raw)
To: nikolay; +Cc: netdev, roopa, sashok, David.Laight
In-Reply-To: <1474381042-15344-1-git-send-email-nikolay@cumulusnetworks.com>
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date: Tue, 20 Sep 2016 16:17:22 +0200
> When I introduced the lastuse member I made a subtle error because it was
> returned as an absolute value but that is meaningless to user-space as it
> doesn't allow to see how old exactly an entry is. Let's make it similar to
> how the bridge returns such values and make it relative to "now" (jiffies).
> This allows us to show the actual age of the entries and is much more
> useful (e.g. user-space daemons can age out entries, iproute2 can display
> the lastuse properly).
>
> Fixes: 43b9e1274060 ("net: ipmr/ip6mr: add support for keeping an entry age")
> Reported-by: Satish Ashok <sashok@cumulusnetworks.com>
> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
> ---
> v2: make sure lastuse is before or equal to jiffies as per David Laight's
> comment
Applied.
^ permalink raw reply
* Re: [PATCH net 0/5] r8152: correct the flow of PHY
From: David Miller @ 2016-09-21 4:56 UTC (permalink / raw)
To: hayeswang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <1394712342-15778-219-Taiwan-albertk@realtek.com>
From: Hayes Wang <hayeswang@realtek.com>
Date: Tue, 20 Sep 2016 16:22:04 +0800
> First, to enable the PHY as early as possible. Some settings may fail if the
> PHY is power down.
>
> Move the other PHY settings to hw_phy_cfg() to make sure the order is correct.
>
> Finally, disable ALDPS and EEE before updating the PHY for RTL8153.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 2/3] net: ethernet: mediatek: add support for GMAC0 connecting with external PHY through TRGMII
From: David Miller @ 2016-09-21 4:50 UTC (permalink / raw)
To: sean.wang; +Cc: john, nbd, netdev, linux-mediatek, keyhaede, objelf
In-Reply-To: <1474358360-29901-3-git-send-email-sean.wang@mediatek.com>
From: <sean.wang@mediatek.com>
Date: Tue, 20 Sep 2016 15:59:19 +0800
> +/*TRGMII RXC control register*/
...
> +/*TRGMII RXC control register*/
...
> +/*TRGMII Interface mode register*/
Please put a space at the beginning and end of comment lines like this.
Thanks.
^ 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