* RE: [RFC PATCH 2/3] x86/io: implement 256-bit IO read and write
From: David Laight @ 2018-03-20 14:40 UTC (permalink / raw)
To: 'Rahul Lakkireddy', Thomas Gleixner
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, mingo@redhat.com, hpa@zytor.com,
davem@davemloft.net, akpm@linux-foundation.org,
torvalds@linux-foundation.org, Ganesh GR, Nirranjan Kirubaharan,
Indranil Choudhury
In-Reply-To: <20180320133206.GB25574@chelsio.com>
From: Rahul Lakkireddy
> Sent: 20 March 2018 13:32
...
> On High Availability Server, the logs of the failing system must be
> collected as quickly as possible. So, we're concerned with the amount
> of time taken to collect our large on-chip memory. We see improvement
> in doing 256-bit reads at a time.
Two other options:
1) Get the device to DMA into host memory.
2) Use mmap() (and vm_iomap_memory() in your driver) to get direct
userspace access to the (I assume) PCIe memory space.
You can then use whatever copy instructions the cpu has.
(Just don't use memcpy().)
David
^ permalink raw reply
* Re: [PATCH] Add possibility to turn off promiscuous mode
From: David Miller @ 2018-03-20 14:36 UTC (permalink / raw)
To: s.mondwurf; +Cc: vbridger, netdev, nios2-dev
In-Reply-To: <1ad29d4d-ec70-381e-9d57-86f916d6799c@astro-kom.de>
From: Stephan Mondwurf <s.mondwurf@astro-kom.de>
Date: Tue, 20 Mar 2018 11:28:20 +0100
> The driver is capable of switching on the promiscuous mode.
>
> This patch adds the possibility to turn it off again.
>
> Signed-off-by: Stephan Mondwurf <s.mondwurf@astro-kom.de>
Please fix your patch submissions.
Your subject line should have an appropriate subsystem prefix, for
drivers like this simply "altera: " is sufficient. You should
also specify what tree your patch is targetting in the '[PATCH]'
string. So together that means:
Subject: [PATCH net] altera: Add possibility to turn off promiscuous mode
or:
Subject: [PATCH net-next] altera: Add possibility to turn off promiscuous mode
Also, your patches has both been completely corrupted by your email
client. Long lines have been split up.
Please email the patch to yourself, and try to apply it. Do not
resubmit the patch to the list here until you can do that
successfully.
Thank you.
^ permalink raw reply
* Re: [RFC PATCH] net: phy: Added device tree binding for dev-addr and dev-addr code check-up and usage
From: Andrew Lunn @ 2018-03-20 14:30 UTC (permalink / raw)
To: Vicentiu Galanopulo
Cc: f.fainelli, netdev, linux-kernel, robh+dt, mark.rutland, davem,
marcel, devicetree, madalin.bucur, alexandru.marginean
In-Reply-To: <20180320134615.17817-1-vicentiu.galanopulo@nxp.com>
On Tue, Mar 20, 2018 at 08:46:15AM -0500, Vicentiu Galanopulo wrote:
> Reason for this patch is that the Inphi PHY
> has a vendor specific address space for accessing
> the C45 MDIO registers - starting from 0x1e.
>
> A new function has been added, get_phy_c45_dev_addr,
> which loops through all the PHY device nodes under
> a MDIO bus node and looks for the <dev-addr> property. If
> it's not set/found, the get_phy_c45_devs_in_pkg,
> will be called with the value 0 as dev_addr parameter,
> else it will be called with the dev-addr property
> value from the device tree.
This seems like the wrong way to implement this. How about:
of_mdiobus_register(), when it loops over the children, looks for the
new property. If found, it passed dev-id to of_mdiobus_register_phy().
That passes it to get_phy_device(). I think get_phy_device() can then
set the ID in c45_ids, before passing it to
get_phy_id(). get_phy_c45_ids() will first look at devices in package
and can add further devices to c45_ids. It will then probe both those
found, and the static one you added.
Andrew
^ permalink raw reply
* Re: pull request: bluetooth 2018-03-16
From: David Miller @ 2018-03-20 14:29 UTC (permalink / raw)
To: marcel; +Cc: johan.hedberg, linux-bluetooth, netdev
In-Reply-To: <2162D348-7B5F-4693-87AB-8835A1638CF3@holtmann.org>
From: Marcel Holtmann <marcel@holtmann.org>
Date: Tue, 20 Mar 2018 09:44:37 +0100
> any issue with this pull request? I ask since it seems to have
> disappeared from patchwork.
Should be pulled in now, don't know how that happened ;-)
Thanks.
^ permalink raw reply
* Re: [bpf-next V2 PATCH 10/15] xdp: rhashtable with allocator ID to pointer mapping
From: Jesper Dangaard Brouer @ 2018-03-20 14:27 UTC (permalink / raw)
To: Jason Wang
Cc: netdev, BjörnTöpel, magnus.karlsson, eugenia,
John Fastabend, Eran Ben Elisha, Saeed Mahameed, galp,
Daniel Borkmann, Alexei Starovoitov, Tariq Toukan, brouer
In-Reply-To: <6950eb76-8e3d-60f2-6de1-005a4e4fd3f6@redhat.com>
On Tue, 20 Mar 2018 10:26:50 +0800
Jason Wang <jasowang@redhat.com> wrote:
> On 2018年03月19日 17:48, Jesper Dangaard Brouer wrote:
> > On Fri, 16 Mar 2018 16:45:30 +0800
> > Jason Wang <jasowang@redhat.com> wrote:
> >
> >> On 2018年03月10日 00:07, Jesper Dangaard Brouer wrote:
> >>> On Fri, 9 Mar 2018 21:07:36 +0800
> >>> Jason Wang <jasowang@redhat.com> wrote:
> >>>
> >>>>>>> Use the IDA infrastructure for getting a cyclic increasing ID number,
> >>>>>>> that is used for keeping track of each registered allocator per
> >>>>>>> RX-queue xdp_rxq_info.
> >>>>>>>
> >>>>>>> Signed-off-by: Jesper Dangaard Brouer<brouer@redhat.com>
> >>>>>> A stupid question is, can we manage to unify this ID with NAPI id?
> >>>>> Sorry I don't understand the question?
> >>>> I mean can we associate page poll pointer to napi_struct, record NAPI id
> >>>> in xdp_mem_info and do lookup through NAPI id?
> >>> No. The driver can unreg/reg a new XDP memory model,
> >>
> >> Is there an actual use case for this?
> >
> > I believe this is the common use case. When attaching an XDP/bpf prog,
> > then the driver usually want to change the RX-ring memory model
> > (different performance trade off).
>
> Right, but a single driver should only have one XDP memory model.
No! -- a driver can have multiple XDP memory models, based on different
performance trade offs and hardware capabilities.
The mlx5 (100Gbit/s) driver/hardware is a good example, which need
different memory models. It already support multiple RX memory models,
depending on HW support. So, I predict that we hit at performance
limit around 42Mpps on PCIe (I can measure 36Mpps), this is due to
PCI-express translations/sec limit. The mlx5 HW supports a compressed
descriptor format which deliver packets in several pages (based on
offset and len), thus lowering the needed PCIe transactions. The
pitfall is that this comes tail room limitations, which can be okay if
e.g. the users use-case does not involve cpumap.
Plus, when a driver need to support AF_XDP zero-copy, that also count
as another XDP memory model...
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: interdependencies with cxgb4 and iw_cxgb4
From: Leon Romanovsky @ 2018-03-20 14:03 UTC (permalink / raw)
To: Steve Wise
Cc: 'David Miller', rajur, dledford, linux-rdma, jgg, netdev,
bharat, ganeshgr, rahul.lakkireddy
In-Reply-To: <01a201d3c051$eebbded0$cc339c70$@opengridcomputing.com>
[-- Attachment #1: Type: text/plain, Size: 1570 bytes --]
On Tue, Mar 20, 2018 at 08:47:04AM -0500, Steve Wise wrote:
> > From: Steve Wise <swise@opengridcomputing.com>
> > Date: Mon, 19 Mar 2018 14:50:57 -0500
> >
> > > Let me ask a dumb question: Why cannot one of the maintaners pull the
> > > commit from the other mainainer's git repo directly? IE why have this
> > > third trusted/signed git repo that has to be on k.o, from which both
> > > maintainers pull? If one of you can pull it in via a patch series,
> > > like you do for all other patches, and then notify the other
> > > maintainer to pull it from the first maintainers' repo if the series
> > > meets the requirements that it needs to be in both maintainers'
> > > repositories? This avoids adding more staging git repos on k.o. But
> > > probably I'm missing something...
> >
> > Tree A may not want all of tree B's changes, and vice versa.
>
> I was thinking the special commit would go into a branch that was based on,
> say rc1 or rc2 of one of the maintainers. Then both maintainers pull that
> into their -next branch. Would that work?
Steve,
It is more or less what we are doing with our shared PR, we just
"offloaded" the overhead of creating and maintaining that special
branch from maintainers. I don't think that anyone here will say no
to you to create that special branch from time to time.
Thanks
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* RE: interdependencies with cxgb4 and iw_cxgb4
From: Steve Wise @ 2018-03-20 13:47 UTC (permalink / raw)
To: 'David Miller'
Cc: rajur, dledford, linux-rdma, jgg, netdev, bharat, ganeshgr,
rahul.lakkireddy
In-Reply-To: <20180319.193440.1570733225238398675.davem@davemloft.net>
> From: Steve Wise <swise@opengridcomputing.com>
> Date: Mon, 19 Mar 2018 14:50:57 -0500
>
> > Let me ask a dumb question:� Why cannot one of the maintaners pull the
> > commit from the other mainainer's git repo directly?� IE why have this
> > third trusted/signed git repo that has to be on k.o, from which both
> > maintainers pull?� If one of you can pull it in via a patch series,
> > like you do for all other patches, and then notify the other
> > maintainer to pull it from the first maintainers' repo if the series
> > meets the requirements that it needs to be in both maintainers'
> > repositories?� This avoids adding more staging git repos on k.o.� But
> > probably I'm missing something...
>
> Tree A may not want all of tree B's changes, and vice versa.
I was thinking the special commit would go into a branch that was based on,
say rc1 or rc2 of one of the maintainers. Then both maintainers pull that
into their -next branch. Would that work?
^ permalink raw reply
* [RFC PATCH] net: phy: Added device tree binding for dev-addr and dev-addr code check-up and usage
From: Vicentiu Galanopulo @ 2018-03-20 13:46 UTC (permalink / raw)
To: andrew, f.fainelli, netdev, linux-kernel, robh+dt, mark.rutland,
davem, marcel, devicetree
Cc: madalin.bucur, alexandru.marginean
Reason for this patch is that the Inphi PHY
has a vendor specific address space for accessing
the C45 MDIO registers - starting from 0x1e.
A new function has been added, get_phy_c45_dev_addr,
which loops through all the PHY device nodes under
a MDIO bus node and looks for the <dev-addr> property. If
it's not set/found, the get_phy_c45_devs_in_pkg,
will be called with the value 0 as dev_addr parameter,
else it will be called with the dev-addr property
value from the device tree.
As a plus to this patch, num_ids in get_phy_c45_ids,
has the value 8 (ARRAY_SIZE(c45_ids->device_ids)), but
the u32 *devs can store 32 devices in the bitfield. If
a device is stored in *devs, in bits 32 to 9, it
will not be found. This is the reason for changing in phy.h,
the size of device_ids array.
Signed-off-by: Vicentiu Galanopulo <vicentiu.galanopulo@nxp.com>
---
Documentation/devicetree/bindings/net/phy.txt | 6 ++
drivers/net/phy/phy_device.c | 80 ++++++++++++++++++++++++++-
include/linux/phy.h | 2 +-
3 files changed, 84 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/phy.txt b/Documentation/devicetree/bindings/net/phy.txt
index d2169a5..82692e2 100644
--- a/Documentation/devicetree/bindings/net/phy.txt
+++ b/Documentation/devicetree/bindings/net/phy.txt
@@ -61,6 +61,11 @@ Optional Properties:
- reset-deassert-us: Delay after the reset was deasserted in microseconds.
If this property is missing the delay will be skipped.
+- dev-addr: If set, it indicates the device address of the PHY to be used
+ when accessing the C45 PHY registers over MDIO. It is used for vendor specific
+ register space addresses that do no conform to standard address for the MDIO
+ registers (e.g. MMD30)
+
Example:
ethernet-phy@0 {
@@ -72,4 +77,5 @@ ethernet-phy@0 {
reset-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
reset-assert-us = <1000>;
reset-deassert-us = <2000>;
+ dev-addr = <0x1e>;
};
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index b285323..35b9a2b 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -442,6 +442,52 @@ static int get_phy_c45_devs_in_pkg(struct mii_bus *bus, int addr, int dev_addr,
}
/**
+ * get_phy_c45_dev_addr - reads the C45 PHY device register address
+ * from the PHY device tree node
+ * @bus: the target MII bus
+ * @addr: PHY address on the MII bus
+ * @dev_addr: where to store the device address of the C45 PHY.
+ *
+ * Description: reads the PHY device address in @dev_addr
+ * from PHY at @addr on @bus.
+ *
+ * Returns: 0 on success, -EIO and -ENODEV on failure.
+ */
+static int get_phy_c45_dev_addr(struct mii_bus *bus,
+ int addr, int *dev_addr)
+{
+ struct device_node *child;
+ u32 reg_addr;
+ int ret;
+
+ if (!bus->dev.of_node)
+ return -ENODEV;
+
+ for_each_available_child_of_node(bus->dev.of_node, child) {
+ ret = of_property_read_u32(child, "reg", ®_addr);
+ if (ret < 0) {
+ dev_err(&bus->dev, "%s has invalid PHY address\n",
+ child->full_name);
+ *dev_addr = 0;
+ return -EINVAL;
+ }
+
+ /* match the device address with the device tree address */
+ if (reg_addr == addr) {
+ ret = of_property_read_u32(child, "dev-addr", dev_addr);
+ if (ret < 0) {
+ dev_warn(&bus->dev, "No PHY device address defined for %s\n",
+ child->full_name);
+ *dev_addr = 0;
+ }
+ break;
+ }
+ }
+
+ return 0;
+}
+
+/**
* get_phy_c45_ids - reads the specified addr for its 802.3-c45 IDs.
* @bus: the target MII bus
* @addr: PHY address on the MII bus
@@ -458,6 +504,9 @@ static int get_phy_c45_ids(struct mii_bus *bus, int addr, u32 *phy_id,
struct phy_c45_device_ids *c45_ids) {
int phy_reg;
int i, reg_addr;
+ int dev_addr = 0;
+ int ret;
+ int dev_reg_addr;
const int num_ids = ARRAY_SIZE(c45_ids->device_ids);
u32 *devs = &c45_ids->devices_in_package;
@@ -475,9 +524,27 @@ static int get_phy_c45_ids(struct mii_bus *bus, int addr, u32 *phy_id,
* 10G PHYs have zero Devices In package,
* e.g. Cortina CS4315/CS4340 PHY.
*/
- phy_reg = get_phy_c45_devs_in_pkg(bus, addr, 0, devs);
+
+ /* Check if the device address
+ * is set in the device tree
+ */
+ ret = get_phy_c45_dev_addr(bus, addr, &dev_addr);
+ /* Exit only when MDIO querying fails
+ * or <reg> property is not set in the
+ * PHY device tree node.
+ */
+ if (ret < 0)
+ return -EIO;
+
+ /* If the device tree property (dev-addr)
+ * is not set, the default value for
+ * dev_addr is 0.
+ */
+ phy_reg = get_phy_c45_devs_in_pkg(bus, addr,
+ dev_addr, devs);
if (phy_reg < 0)
return -EIO;
+
/* no device there, let's get out of here */
if ((*devs & 0x1fffffff) == 0x1fffffff) {
*phy_id = 0xffffffff;
@@ -493,13 +560,20 @@ static int get_phy_c45_ids(struct mii_bus *bus, int addr, u32 *phy_id,
if (!(c45_ids->devices_in_package & (1 << i)))
continue;
- reg_addr = MII_ADDR_C45 | i << 16 | MII_PHYSID1;
+ /* If dev-addr is set in the device tree,
+ * use that property value for querying
+ * the PHY device ID.
+ */
+
+ dev_reg_addr = (!!dev_addr ? dev_addr : i) << 16;
+ reg_addr = MII_ADDR_C45 | dev_reg_addr | MII_PHYSID1;
phy_reg = mdiobus_read(bus, addr, reg_addr);
if (phy_reg < 0)
return -EIO;
c45_ids->device_ids[i] = (phy_reg & 0xffff) << 16;
- reg_addr = MII_ADDR_C45 | i << 16 | MII_PHYSID2;
+ dev_reg_addr = (!!dev_addr ? dev_addr : i) << 16;
+ reg_addr = MII_ADDR_C45 | dev_reg_addr | MII_PHYSID2;
phy_reg = mdiobus_read(bus, addr, reg_addr);
if (phy_reg < 0)
return -EIO;
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 5a9b175..c3b3633 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -360,7 +360,7 @@ enum phy_state {
*/
struct phy_c45_device_ids {
u32 devices_in_package;
- u32 device_ids[8];
+ u32 device_ids[32];
};
/* phy_device: An instance of a PHY
--
2.7.4
^ permalink raw reply related
* Re: [RFC PATCH 0/3] kernel: add support for 256-bit IO access
From: Rahul Lakkireddy @ 2018-03-20 13:45 UTC (permalink / raw)
To: Christoph Hellwig
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com,
hpa@zytor.com, davem@davemloft.net, akpm@linux-foundation.org,
torvalds@linux-foundation.org, Ganesh GR, Nirranjan Kirubaharan,
Indranil Choudhury
In-Reply-To: <20180319152722.GA31104@infradead.org>
On Monday, March 03/19/18, 2018 at 20:57:22 +0530, Christoph Hellwig wrote:
> On Mon, Mar 19, 2018 at 07:50:33PM +0530, Rahul Lakkireddy wrote:
> > This series of patches add support for 256-bit IO read and write.
> > The APIs are readqq and writeqq (quad quadword - 4 x 64), that read
> > and write 256-bits at a time from IO, respectively.
>
> What a horrible name. please encode the actual number of bits instead.
Ok. Will change it to read256() and write256().
Thanks,
Rahul
^ permalink raw reply
* Re: [RFC PATCH 2/3] x86/io: implement 256-bit IO read and write
From: Andy Shevchenko @ 2018-03-20 13:44 UTC (permalink / raw)
To: Rahul Lakkireddy
Cc: Thomas Gleixner, x86@kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, mingo@redhat.com, hpa@zytor.com,
davem@davemloft.net, akpm@linux-foundation.org,
torvalds@linux-foundation.org, Ganesh GR, Nirranjan Kirubaharan,
Indranil Choudhury
In-Reply-To: <20180320133206.GB25574@chelsio.com>
On Tue, Mar 20, 2018 at 3:32 PM, Rahul Lakkireddy
<rahul.lakkireddy@chelsio.com> wrote:
> On Monday, March 03/19/18, 2018 at 20:13:10 +0530, Thomas Gleixner wrote:
>> On Mon, 19 Mar 2018, Rahul Lakkireddy wrote:
>> Aside of that I very much doubt that this is faster than 4 consecutive
>> 64bit reads/writes as you have the full overhead of
>> kernel_fpu_begin()/end() for each access.
>>
>> You did not provide any numbers for this so its even harder to
>> determine.
>>
>
> Sorry about that. Here are the numbers with and without this series.
>
> When reading up to 2 GB on-chip memory via MMIO, the time taken:
>
> Without Series With Series
> (64-bit read) (256-bit read)
>
> 52 seconds 26 seconds
>
> As can be seen, we see good improvement with doing 256-bits at a
> time.
But this is kinda synthetic test, right?
If you run in a normal use case where kernel not only collecting logs,
but doing something else, especially with frequent userspace
interaction, would be trend the same?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [RFC PATCH 2/3] x86/io: implement 256-bit IO read and write
From: Rahul Lakkireddy @ 2018-03-20 13:32 UTC (permalink / raw)
To: Thomas Gleixner
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, mingo@redhat.com, hpa@zytor.com,
davem@davemloft.net, akpm@linux-foundation.org,
torvalds@linux-foundation.org, Ganesh GR, Nirranjan Kirubaharan,
Indranil Choudhury
In-Reply-To: <alpine.DEB.2.21.1803191525010.2010@nanos.tec.linutronix.de>
On Monday, March 03/19/18, 2018 at 20:13:10 +0530, Thomas Gleixner wrote:
> On Mon, 19 Mar 2018, Rahul Lakkireddy wrote:
>
> > Use VMOVDQU AVX CPU instruction when available to do 256-bit
> > IO read and write.
>
> That's not what the patch does. See below.
>
> > Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
> > Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
>
> That Signed-off-by chain is wrong....
>
> > +#ifdef CONFIG_AS_AVX
> > +#include <asm/fpu/api.h>
> > +
> > +static inline u256 __readqq(const volatile void __iomem *addr)
> > +{
> > + u256 ret;
> > +
> > + kernel_fpu_begin();
> > + asm volatile("vmovdqu %0, %%ymm0" :
> > + : "m" (*(volatile u256 __force *)addr));
> > + asm volatile("vmovdqu %%ymm0, %0" : "=m" (ret));
> > + kernel_fpu_end();
> > + return ret;
>
> You _cannot_ assume that the instruction is available just because
> CONFIG_AS_AVX is set. The availability is determined by the runtime
> evaluated CPU feature flags, i.e. X86_FEATURE_AVX.
>
Ok. Will add boot_cpu_has(X86_FEATURE_AVX) check as well.
> Aside of that I very much doubt that this is faster than 4 consecutive
> 64bit reads/writes as you have the full overhead of
> kernel_fpu_begin()/end() for each access.
>
> You did not provide any numbers for this so its even harder to
> determine.
>
Sorry about that. Here are the numbers with and without this series.
When reading up to 2 GB on-chip memory via MMIO, the time taken:
Without Series With Series
(64-bit read) (256-bit read)
52 seconds 26 seconds
As can be seen, we see good improvement with doing 256-bits at a
time.
> As far as I can tell the code where you are using this is a debug
> facility. What's the point? Debug is hardly a performance critical problem.
>
On High Availability Server, the logs of the failing system must be
collected as quickly as possible. So, we're concerned with the amount
of time taken to collect our large on-chip memory. We see improvement
in doing 256-bit reads at a time.
Thanks,
Rahul
^ permalink raw reply
* RE: [RFC PATCH 0/3] kernel: add support for 256-bit IO access
From: David Laight @ 2018-03-20 13:30 UTC (permalink / raw)
To: 'Ingo Molnar', Thomas Gleixner
Cc: 'Rahul Lakkireddy', x86@kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
mingo@redhat.com, hpa@zytor.com, davem@davemloft.net,
akpm@linux-foundation.org, torvalds@linux-foundation.org,
ganeshgr@chelsio.com, nirranjan@chelsio.com, indranil@chelsio.com,
Andy Lutomirski, Peter Zijlstra, Fenghua Yu, Eric Biggers
In-Reply-To: <20180320105427.bm4od7cpessbraag@gmail.com>
From: Ingo Molnar
> Sent: 20 March 2018 10:54
...
> Note that a generic version might still be worth trying out, if and only if it's
> safe to access those vector registers directly: modern x86 CPUs will do their
> non-constant memcpy()s via the common memcpy_erms() function - which could in
> theory be an easy common point to be (cpufeatures-) patched to an AVX2 variant, if
> size (and alignment, perhaps) is a multiple of 32 bytes or so.
>
> Assuming it's correct with arbitrary user-space FPU state and if it results in any
> measurable speedups, which might not be the case: ERMS is supposed to be very
> fast.
>
> So even if it's possible (which it might not be), it could end up being slower
> than the ERMS version.
Last I checked memcpy() was implemented as 'rep movsb' on the latest Intel cpus.
Since memcpy_to/fromio() get aliased to memcpy() this generates byte copies.
The previous 'fastest' version of memcpy() was ok for uncached locations.
For PCIe I suspect that the actual instructions don't make a massive difference.
I'm not even sure interleaving two transfers makes any difference.
What makes a huge difference for memcpy_fromio() is the size of the register.
The time taken for a read will be largely independent of the width of the
register used.
David
^ permalink raw reply
* Re: [RFC v2 0/2] kernel: add support to collect hardware logs in crash recovery kernel
From: Rahul Lakkireddy @ 2018-03-20 13:30 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Indranil Choudhury,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org,
Nirranjan Kirubaharan,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org, Ganesh GR
In-Reply-To: <20180319082211.6651b45a@xeon-e3>
On Monday, March 03/19/18, 2018 at 20:52:11 +0530, Stephen Hemminger wrote:
> On Mon, 19 Mar 2018 13:25:56 +0530
> Rahul Lakkireddy <rahul.lakkireddy-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org> wrote:
>
> > On Friday, March 03/16/18, 2018 at 16:42:03 +0530, Rahul Lakkireddy wrote:
> > > On production servers running variety of workloads over time, kernel
> > > panic can happen sporadically after days or even months. It is
> > > important to collect as much debug logs as possible to root cause
> > > and fix the problem, that may not be easy to reproduce. Snapshot of
> > > underlying hardware/firmware state (like register dump, firmware
> > > logs, adapter memory, etc.), at the time of kernel panic will be very
> > > helpful while debugging the culprit device driver.
> > >
> > > This series of patches add new generic framework that enable device
> > > drivers to collect device specific snapshot of the hardware/firmware
> > > state of the underlying device in the crash recovery kernel. In crash
> > > recovery kernel, the collected logs are exposed via /proc/crashdd/
> > > directory, which is copied by user space scripts for post-analysis.
> > >
> > > A kernel module crashdd is newly added. In crash recovery kernel,
> > > crashdd exposes /proc/crashdd/ directory containing device specific
> > > hardware/firmware logs.
> > >
> > > The sequence of actions done by device drivers to append their device
> > > specific hardware/firmware logs to /proc/crashdd/ directory are as
> > > follows:
> > >
> > > 1. During probe (before hardware is initialized), device drivers
> > > register to the crashdd module (via crashdd_add_dump()), with
> > > callback function, along with buffer size and log name needed for
> > > firmware/hardware log collection.
> > >
> > > 2. Crashdd creates a driver's directory under /proc/crashdd/<driver>.
> > > Then, it allocates the buffer with requested size and invokes the
> > > device driver's registered callback function.
> > >
> > > 3. Device driver collects all hardware/firmware logs into the buffer
> > > and returns control back to crashdd.
> > >
> > > 4. Crashdd exposes the buffer as a file via
> > > /proc/crashdd/<driver>/<dump_file>.
> > >
> > > 5. User space script (/usr/lib/kdump/kdump-lib-initramfs.sh) copies
> > > the entire /proc/crashdd/ directory to /var/crash/ directory.
> > >
> > > Patch 1 adds crashdd module to allow drivers to register callback to
> > > collect the device specific hardware/firmware logs. The module also
> > > exports /proc/crashdd/ directory containing the hardware/firmware logs.
> > >
> > > Patch 2 shows a cxgb4 driver example using the API to collect
> > > hardware/firmware logs in crash recovery kernel, before hardware is
> > > initialized. The logs for the devices are made available under
> > > /proc/crashdd/cxgb4/ directory.
> > >
> > > Suggestions and feedback will be much appreciated.
> > >
> > > Thanks,
> > > Rahul
> > >
> > > RFC v1: https://www.spinics.net/lists/netdev/msg486562.html
> > >
> > > ---
> > > v2:
> > > - Added new crashdd module that exports /proc/crashdd/ containing
> > > driver's registered hardware/firmware logs in patch 1.
> > > - Replaced the API to allow drivers to register their hardware/firmware
> > > log collect routine in crash recovery kernel in patch 1.
> > > - Updated patch 2 to use the new API in patch 1.
> > >
> > > Rahul Lakkireddy (2):
> > > proc/crashdd: add API to collect hardware dump in second kernel
> > > cxgb4: collect hardware dump in second kernel
> > >
> > > drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 4 +
> > > drivers/net/ethernet/chelsio/cxgb4/cxgb4_cudbg.c | 25 +++
> > > drivers/net/ethernet/chelsio/cxgb4/cxgb4_cudbg.h | 3 +
> > > drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 12 ++
> > > fs/proc/Kconfig | 11 +
> > > fs/proc/Makefile | 1 +
> > > fs/proc/crashdd.c | 263 +++++++++++++++++++++++
> > > include/linux/crashdd.h | 43 ++++
> > > 8 files changed, 362 insertions(+)
> > > create mode 100644 fs/proc/crashdd.c
> > > create mode 100644 include/linux/crashdd.h
> > >
> > > --
> > > 2.14.1
> > >
> >
> > Does anyone have any comments with this approach? If there are no
> > comments, then I'll re-spin this RFC to Patch series.
> >
> > Thanks,
> > Rahul
>
> This does look like it gives useful data, but it is not clear that this can
> not already be done with existing API's or small extensions.
>
> Introducing a new /proc interface and one that is mostly device specific is
> unlikely to be greeted with a warm reception by the current Linux kernel community.
>
> For example, getting firmware logs seems like something more related to
> ethtool or sysfs.
The /proc/crashdd/ is only exposed in 2nd (crash recovery) kernel.
This is similar to /proc/vmcore. Since vmcore is exported via
/proc/ interface, I've exported the device specific logs also via
/proc/crashdd/.
I can change to sysfs if that is the preferred approach. Does
/sys/crashdd/ sound good?
Thanks,
Rahul
^ permalink raw reply
* Re: [rds-devel] [PATCH RFC RFC] rds: Use NETDEV_UNREGISTER in rds_tcp_dev_event() (then kill NETDEV_UNREGISTER_FINAL)
From: Sowmini Varadhan @ 2018-03-20 13:29 UTC (permalink / raw)
To: H??kon Bugge
Cc: Kirill Tkhai, rds-devel, OFED mailing list, netdev, edumazet,
davem
In-Reply-To: <CBB6A644-8650-41F5-800B-A34DEFBB2C4C@oracle.com>
On (03/20/18 12:37), H??kon Bugge wrote:
>
> A little nit below. And some spelling issues in existing commentary
> you can consider fixing, since you reshuffle this file considerable.
> > + if (net != &init_net && rtn->ctl_table)
> > + kfree(rtn->ctl_table);
>
> Well, this comes from the existing code, but as pointed out by Linus
> recently, kfree() handles NULL pointers. So, if rtn->ctl_table is
> NULL most likely, the code is OK _if_ you add an unlikely() around the
> if-clause. Otherwise, the ??? && rtn->ctl_table??? can simply be removed.
As you observe correctly, this comes from the existing code,
and is unrelated to the contents of the commit comment.
So if we feel passionately about htis, let us please fix this
separately, with its own ceremony.
> s/when/When/
> s/parameters,this/parameters, this/
>
> Well, not part of your commit.
As above.
>
>
> > * function resets the RDS connections in that netns so that we can
>
> Two double spaces incidents above
>
> Not part of your commit
As above.
Thanks much.
--Sowmini
^ permalink raw reply
* Re: linux-next on x60: network manager often complains "network is disabled" after resume
From: Dan Williams @ 2018-03-20 13:12 UTC (permalink / raw)
To: Pavel Machek
Cc: Woody Suwalski, Rafael J. Wysocki, kernel list,
Linux-pm mailing list, Netdev list
In-Reply-To: <20180320080334.GA31772@amd>
On Tue, 2018-03-20 at 09:03 +0100, Pavel Machek wrote:
> On Mon 2018-03-19 12:45:49, Dan Williams wrote:
> > On Mon, 2018-03-19 at 18:33 +0100, Pavel Machek wrote:
> > > On Mon 2018-03-19 10:40:08, Dan Williams wrote:
> > > > On Mon, 2018-03-19 at 10:21 +0100, Pavel Machek wrote:
> > > > > On Mon 2018-03-19 05:17:45, Woody Suwalski wrote:
> > > > > > Pavel Machek wrote:
> > > > > > > Hi!
> > > > > > >
> > > > > > > With recent linux-next, after resume networkmanager often
> > > > > > > claims
> > > > > > > that
> > > > > > > "network is disabled". Sometimes suspend/resume clears
> > > > > > > that.
> > > > > > >
> > > > > > > Any ideas? Does it work for you?
> > > > > > >
> > > > > > >
> > > > > > > Pavel
> > > > > >
> > > > > > Tried the 4.16-rc6 with nm 1.4.4 - I do not see the issue.
> > > > >
> > > > > Thanks for testing... but yes, 4.16 should be ok. If not
> > > > > fixed,
> > > > > problem will appear in 4.17-rc1.
> > > >
> > > > Where does the complaint occur? In the GUI, or with nmcli, or
> > > > somewhere else? Also, what's the output of "nmcli dev" after
> > > > resume?
> > >
> > > In the GUI. I click in place where I'd select access point, and
> > > menu
> > > does not show up, telling me that "network is disabled".
> >
> > Ok, what does 'nmcli dev' and 'nmcli radio' show?
>
> Broken state.
>
> pavel@amd:~$ nmcli dev
> DEVICE TYPE STATE CONNECTION
> eth1 ethernet unavailable --
> lo loopback unmanaged --
> wlan0 wifi unmanaged --
If the state is "unmanaged" on resume, that would indicate a problem
with sleep/wake and likely not a kernel network device issue.
We should probably move this discussion to the NM lists to debug
further. Before you suspend, run "nmcli gen log level trace" to turn
on full debug logging, then reproduce the issue, and send a pointer to
those logs (scrubbed for anything you consider sensitive) to the NM
mailing list.
Dan
> pavel@amd:~$ nmcli radio
> WIFI-HW WIFI WWAN-HW WWAN
> enabled enabled enabled enabled
> pavel@amd:~$ uname -a
> Linux amd 4.16.0-rc5-next-20180314+ #31 SMP Thu Mar 15 14:27:19 CET
> 2018 i686 GNU/Linux
>
> Let me suspend/resume. I was lucky and got it into working state:
>
> pavel@amd:~$ nmcli dev
> DEVICE TYPE STATE CONNECTION
> wlan0 wifi connected openwireless.org
> eth1 ethernet unavailable --
> lo loopback unmanaged --
> pavel@amd:~$ nmcli radio
> WIFI-HW WIFI WWAN-HW WWAN
> enabled enabled enabled enabled
> paveamd:~$
>
> Best regards,
>
> Pavel
>
^ permalink raw reply
* [PATCH] test_bpf: Fix testing with CONFIG_BPF_JIT_ALWAYS_ON=y on other arches
From: Thadeu Lima de Souza Cascardo @ 2018-03-20 12:58 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Yonghong Song, Daniel Borkmann, Alexei Starovoitov
Function bpf_fill_maxinsns11 is designed to not be able to be JITed on
x86_64. So, it fails when CONFIG_BPF_JIT_ALWAYS_ON=y, and
commit 09584b406742 ("bpf: fix selftests/bpf test_kmod.sh failure when
CONFIG_BPF_JIT_ALWAYS_ON=y") makes sure that failure is detected on that
case.
However, it does not fail on other architectures, which have a different
JIT compiler design. So, test_bpf has started to fail to load on those.
After this fix, test_bpf loads fine on both x86_64 and ppc64el.
Fixes: 09584b406742 ("bpf: fix selftests/bpf test_kmod.sh failure when CONFIG_BPF_JIT_ALWAYS_ON=y")
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
---
lib/test_bpf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/test_bpf.c b/lib/test_bpf.c
index 2efb213716faa..3e9335493fe49 100644
--- a/lib/test_bpf.c
+++ b/lib/test_bpf.c
@@ -5467,7 +5467,7 @@ static struct bpf_test tests[] = {
{
"BPF_MAXINSNS: Jump, gap, jump, ...",
{ },
-#ifdef CONFIG_BPF_JIT_ALWAYS_ON
+#if defined(CONFIG_BPF_JIT_ALWAYS_ON) && defined(CONFIG_X86)
CLASSIC | FLAG_NO_DATA | FLAG_EXPECTED_FAIL,
#else
CLASSIC | FLAG_NO_DATA,
--
2.15.1
^ permalink raw reply related
* Re: [PATCH] mlx5: Remove call to ida_pre_get
From: Maor Gottlieb @ 2018-03-20 12:41 UTC (permalink / raw)
To: Saeed Mahameed, willy@infradead.org
Cc: Matan Barak, netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
leon@kernel.org
In-Reply-To: <1521516573.32324.63.camel@mellanox.com>
On 3/20/2018 5:29 AM, Saeed Mahameed wrote:
> On Thu, 2018-03-15 at 18:30 -0700, Matthew Wilcox wrote:
>> On Thu, Mar 15, 2018 at 11:58:07PM +0000, Saeed Mahameed wrote:
>>> On Wed, 2018-03-14 at 19:57 -0700, Matthew Wilcox wrote:
>>>> From: Matthew Wilcox <mawilcox@microsoft.com>
>>>>
>>>> The mlx5 driver calls ida_pre_get() in a loop for no readily
>>>> apparent
>>>> reason. The driver uses ida_simple_get() which will call
>>>> ida_pre_get()
>>>> by itself and there's no need to use ida_pre_get() unless using
>>>> ida_get_new().
>>>>
>>> Hi Matthew,
>>>
>>> Is this is causing any issues ? or just a simple cleanup ?
>> I'm removing the API. At the end of this cleanup, there will be no
>> more
>> preallocation; instead we will rely on the slab allocator not
>> sucking.
>>
> Ok, Seems reasonable, I am ok with this.
>
>>> Adding Maor, the author of this change,
>>>
>>> I believe the idea is to speed up insert_fte (which calls
>>> ida_simple_get) since insert_fte runs under the FTE write
>>> semaphore,
>>> in this case if ida_pre_get was successful before taking the
>>> semaphore
>>> for all the FTE nodes in the loop, this will be a huge win for
>>> ida_simple_get which will immediately return success without even
>>> trying to allocate.
>> I think that's misguided. The IDA allocator is only going to
>> allocate
>> memory once in every 1024 allocations. Also, it does try to
>> allocate,
>> even if there are preallocated nodes. So you're just wasting time,
>> unfortunately.
>>
> Well just by looking at the code you can tell for sure that
> two consecutive calls to ida_pre_get will result in one allocation
> only.
> due to "if (!this_cpu_read(ida_bitmap))"
>
> but i didn't dig into details and didn't go through the whole
> ida_get_new_above, so i will count on your judgment here.
>
> Still i would like to wait for Maor's input here, the author..
> I Will ping him today.
>
> Thanks,
> Saeed.
Saeed, Matan and I okay with this fix as well, it looks like it
shouldn't impact on the insertion rate.
^ permalink raw reply
* Re: DTS for our Configuration
From: Andrew Lunn @ 2018-03-20 12:38 UTC (permalink / raw)
To: Alayev Michael; +Cc: netdev@vger.kernel.org, Efter Yoram, Dror Alon
In-Reply-To: <48F7D4389F30BA4383F214EE802BA471017065554B@EXS10.iai.co.il>
On Tue, Mar 20, 2018 at 09:12:18AM +0000, Alayev Michael wrote:
> Hello Andrew,
>
> Please see my comments below in red with some important highlights.
Hi Michael
Please don't use html encrypted emails. Please use quoting as
everybody else does on this list.
> I added the ethernet parameter referencing to gem0. Still cant detect the internal phys and I get kernel panic:
> mdio_bus e000b000.ethernet-ffffffff: /amba/ethernet@e000b000/fixed-link has invalid PHY address
I think this is a problem with the macb driver. To me, it looks like
you are going to have to make some changes to the driver to make this
work. Normally the MDIO bus children are placed within a container
node, often called 'mdio-bus' or simply 'mdio'. See for example
Documentation/devicetree/bindings/net/fsl-fec.txt. The macb driver
does not do this. It passed the main DT node of the device to
of_mdiobus_register(). It then walks all the children assuming they
devices on the MDIO bus. But the first child it finds is the
'fixed-link'. This is not supposed to be a child of the bus, which is
why it goes wrong.
> mv88e6085 e000b000.ethernet-ffffffff:1d: switch 0xa10 detected: Marvell 88E6390X, revision 1
> libphy: mv88e6xxx SMI: probed
> mv88e6085 e000b000.ethernet-ffffffff:1c: switch 0xa10 detected: Marvell 88E6390X, revision 1
> libphy: mv88e6xxx SMI: probed
> mv88e6085: probe of e000b000.ethernet-ffffffff:1c failed with error -16
> mdio_bus e000b000.ethernet-ffffffff: scan phy fixed-link at address 1
> Unable to handle kernel NULL pointer dereference at virtual address 00000004
> pgd = c0004000
> [00000004] *pgd=00000000
> Internal error: Oops - BUG: 17 [#1] PREEMPT SMP ARM
Please include the fill panic details. The stack trace can be very
useful.
Andrew
^ permalink raw reply
* Re: [PATCH v2] netfilter: nf_tables: remove VLA usage
From: Pablo Neira Ayuso @ 2018-03-20 12:37 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Jozsef Kadlecsik, Florian Westphal, David S. Miller,
netfilter-devel, coreteam, netdev, linux-kernel,
Gustavo A. R. Silva
In-Reply-To: <20180313031617.GA2204@embeddedgus>
On Mon, Mar 12, 2018 at 10:16:17PM -0500, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wvla, remove VLA and replace it
> with dynamic memory allocation.
>
> From a security viewpoint, the use of Variable Length Arrays can be
> a vector for stack overflow attacks. Also, in general, as the code
> evolves it is easy to lose track of how big a VLA can get. Thus, we
> can end up having segfaults that are hard to debug.
>
> Also, fixed as part of the directive to remove all VLAs from
> the kernel: https://lkml.org/lkml/2018/3/7/621
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] netfilter: nfnetlink_cthelper: Remove VLA usage
From: Pablo Neira Ayuso @ 2018-03-20 12:36 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Jozsef Kadlecsik, Florian Westphal, David S. Miller,
netfilter-devel, coreteam, netdev, linux-kernel, Kernel Hardening,
Kees Cook, Gustavo A. R. Silva
In-Reply-To: <20180313002138.GA27280@embeddedgus>
On Mon, Mar 12, 2018 at 07:21:38PM -0500, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wvla, remove VLA and replace it
> with dynamic memory allocation.
>
> From a security viewpoint, the use of Variable Length Arrays can be
> a vector for stack overflow attacks. Also, in general, as the code
> evolves it is easy to lose track of how big a VLA can get. Thus, we
> can end up having segfaults that are hard to debug.
>
> Also, fixed as part of the directive to remove all VLAs from
> the kernel: https://lkml.org/lkml/2018/3/7/621
also applied, thanks.
^ permalink raw reply
* Re: [PATCH] netfilter: cttimeout: remove VLA usage
From: Pablo Neira Ayuso @ 2018-03-20 12:36 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Jozsef Kadlecsik, Florian Westphal, David S. Miller,
netfilter-devel, coreteam, netdev, linux-kernel, Kernel Hardening,
Kees Cook, Gustavo A. R. Silva
In-Reply-To: <20180312231442.GA22071@embeddedgus>
On Mon, Mar 12, 2018 at 06:14:42PM -0500, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wvla, remove VLA and replace it
> with dynamic memory allocation.
>
> From a security viewpoint, the use of Variable Length Arrays can be
> a vector for stack overflow attacks. Also, in general, as the code
> evolves it is easy to lose track of how big a VLA can get. Thus, we
> can end up having segfaults that are hard to debug.
>
> Also, fixed as part of the directive to remove all VLAs from
> the kernel: https://lkml.org/lkml/2018/3/7/621
Applied, thanks.
^ permalink raw reply
* Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?
From: Frantisek Rysanek @ 2018-03-20 12:23 UTC (permalink / raw)
To: Andrew Lunn, netdev
In-Reply-To: <20180320120936.GA19142@lunn.ch>
On 20 Mar 2018 at 13:09, Andrew Lunn wrote:
> > i2cdetect has found three i2c slaves (identical layout in both SFP's)
> > at addresses 0x50, 0x51 and 0x56.
> > What are they? EEPROM, DDM and "MDIO over i2c" ?
> > The SFP's likely lack a proper SFP MSA data structure.
>
> 0x50 and 0x51 are EEPROM like. See drivers/net/phy/sfp.c. The standard
> at24 EEPROM driver can also read it. And so should the SFP code in the
> igb driver!
>
Yes - "should" is the right way to put it.
Looking around, I'm wondering how much general-purpose hardware gets
sold with an Intel gigabit chip and SFP sockets. Note: sockets for
actual SFP's, rather than SFP-size transceivers soldered onboard (and
hardwired in the i210 config EEPROM). It took me quite a while to
find such a board from DeLock.
I mean to say that I doubt how much actual testing on humans this i2c
code has enjoyed :-) but admittedly I'm being cheeky here, I haven't
reviewed that part of the driver.
Frank
^ permalink raw reply
* Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?
From: Andrew Lunn @ 2018-03-20 12:09 UTC (permalink / raw)
To: Frantisek Rysanek; +Cc: netdev
In-Reply-To: <5AB0CE14.3307.431B163E@Frantisek.Rysanek.post.cz>
> i2cdetect has found three i2c slaves (identical layout in both SFP's)
> at addresses 0x50, 0x51 and 0x56.
> What are they? EEPROM, DDM and "MDIO over i2c" ?
> The SFP's likely lack a proper SFP MSA data structure.
0x50 and 0x51 are EEPROM like. See drivers/net/phy/sfp.c. The standard
at24 EEPROM driver can also read it. And so should the SFP code in the
igb driver!
> Does this make sense as some sort of proprietary standard
> (Cisco, if I should take the vendor's label at face value),
> or is this likely some "3rd-party innovation thinko", not worth
> implementing?
See if drivers/net/phy/mdio-i2c.c is useful. I'm just guessing here.
Andrew
^ permalink raw reply
* Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?
From: Frantisek Rysanek @ 2018-03-20 12:02 UTC (permalink / raw)
To: Andrew Lunn, netdev
In-Reply-To: <20180318144053.GA1188@lunn.ch>
I've taken a look inside the two SFP's.
http://support.fccps.cz/download/adv/frr/ptp/inside_sfps.zip
The uglier, bigger and likely older model (my SFP#2) contains two
PCB's sandwiched, and the key chips are inside the sandwich.
Thus, the photoes don't show much.
The sexier SFP#1 = the one with the Broadcom chip... I believe it's
what it says on the tin:
- the BCM5461SA is directly interfaced to a laser driver chip (pretty
much analog, found a datasheet from Maxim)
- the RX direction seems equally simple, I haven't identified the
chip by the marking, but by pinout it's undoubtedly an RX amplifier
(they're called transimpedance amps, are they?) and, looking at the
PCB traces, its output is directly interfaced to the BCM5461SA.
- there's another BGA chip on the board, smaller than the BCM PHY.
I believe that this is an "SFP MCU". Might be from Maxim or from
someone completely different :-) Not sure whose trademark the "+"
sign is in the chip marking.
I've found a *slightly* more promising "data brief" from Broadcom
for the BCM5461S:
http://infiber.ru/assets/files/products/phy/BCM5461S_Product_Brief.pdf
This one mentions 100Base-FX among the interface formats supported.
I don't believe that the SFP maker would pipe copper MLT3 into the
fiber driver+receiver :-) Note that the block diagram in the Broadcom
PDF contains other minor errors. God knows what the true
functionality is.
The SFP#1 PCB still doesn't look fake to me.
Frank
^ permalink raw reply
* [PATCH v2 net 7/7] net: aquantia: driver version bump
From: Igor Russkikh @ 2018-03-20 11:40 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, David Arcari, Pavel Belous, Igor Russkikh
In-Reply-To: <cover.1521544563.git.igor.russkikh@aquantia.com>
Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
---
drivers/net/ethernet/aquantia/atlantic/ver.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/aquantia/atlantic/ver.h b/drivers/net/ethernet/aquantia/atlantic/ver.h
index 5265b93..a445de6 100644
--- a/drivers/net/ethernet/aquantia/atlantic/ver.h
+++ b/drivers/net/ethernet/aquantia/atlantic/ver.h
@@ -13,7 +13,7 @@
#define NIC_MAJOR_DRIVER_VERSION 2
#define NIC_MINOR_DRIVER_VERSION 0
#define NIC_BUILD_DRIVER_VERSION 2
-#define NIC_REVISION_DRIVER_VERSION 0
+#define NIC_REVISION_DRIVER_VERSION 1
#define AQ_CFG_DRV_VERSION_SUFFIX "-kern"
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox