Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1330788 > unrolled thread
| Started by | David Decotigny <ddecotig@gmail.com> |
|---|---|
| First post | 2016-02-10 01:30 +0100 |
| Last post | 2016-02-18 21:00 +0100 |
| Articles | 4 on this page of 24 — 3 participants |
Back to article view | Back to linux.kernel
[PATCH net-next v8 00/19] new ETHTOOL_GSETTINGS/SSETTINGS API David Decotigny <ddecotig@gmail.com> - 2016-02-10 01:30 +0100
[PATCH net-next v8 16/19] net: core: use __ethtool_get_ksettings David Decotigny <ddecotig@gmail.com> - 2016-02-10 01:40 +0100
[PATCH net-next v8 12/19] net: fcoe: use __ethtool_get_ksettings David Decotigny <ddecotig@gmail.com> - 2016-02-10 01:40 +0100
[PATCH net-next v8 01/19] lib/bitmap.c: conversion routines to/from u32 array David Decotigny <ddecotig@gmail.com> - 2016-02-10 01:40 +0100
Re: [PATCH net-next v8 01/19] lib/bitmap.c: conversion routines to/from u32 array Ben Hutchings <ben@decadent.org.uk> - 2016-02-13 02:10 +0100
[PATCH net-next v8 10/19] net: macvlan: use __ethtool_get_ksettings David Decotigny <ddecotig@gmail.com> - 2016-02-10 01:40 +0100
[PATCH net-next v8 19/19] net: mlx4: use new ETHTOOL_G/SSETTINGS API David Decotigny <ddecotig@gmail.com> - 2016-02-10 01:40 +0100
[PATCH net-next v8 04/19] net: usnic: use __ethtool_get_settings David Decotigny <ddecotig@gmail.com> - 2016-02-10 01:40 +0100
[PATCH net-next v8 11/19] net: team: use __ethtool_get_ksettings David Decotigny <ddecotig@gmail.com> - 2016-02-10 01:40 +0100
[PATCH net-next v8 17/19] net: ethtool: remove unused __ethtool_get_settings David Decotigny <ddecotig@gmail.com> - 2016-02-10 01:40 +0100
[PATCH net-next v8 07/19] net: usnic: use __ethtool_get_ksettings David Decotigny <ddecotig@gmail.com> - 2016-02-10 01:40 +0100
[PATCH net-next v8 09/19] net: ipvlan: use __ethtool_get_ksettings David Decotigny <ddecotig@gmail.com> - 2016-02-10 01:40 +0100
[PATCH net-next v8 14/19] net: 8021q: use __ethtool_get_ksettings David Decotigny <ddecotig@gmail.com> - 2016-02-10 01:40 +0100
[PATCH net-next v8 03/19] net: usnic: remove unused call to ethtool_ops::get_settings David Decotigny <ddecotig@gmail.com> - 2016-02-10 01:40 +0100
[PATCH net-next v8 18/19] net: mlx4: convenience predicate for debug messages David Decotigny <ddecotig@gmail.com> - 2016-02-10 01:40 +0100
[PATCH net-next v8 13/19] net: rdma: use __ethtool_get_ksettings David Decotigny <ddecotig@gmail.com> - 2016-02-10 01:40 +0100
[PATCH net-next v8 08/19] net: bonding: use __ethtool_get_ksettings David Decotigny <ddecotig@gmail.com> - 2016-02-10 01:40 +0100
[PATCH net-next v8 02/19] test_bitmap: unit tests for lib/bitmap.c David Decotigny <ddecotig@gmail.com> - 2016-02-10 01:40 +0100
Re: [PATCH net-next v8 02/19] test_bitmap: unit tests for lib/bitmap.c Ben Hutchings <ben@decadent.org.uk> - 2016-02-13 02:40 +0100
[PATCH net-next v8 06/19] tx4939: use __ethtool_get_ksettings David Decotigny <ddecotig@gmail.com> - 2016-02-10 01:40 +0100
[PATCH net-next v8 15/19] net: bridge: use __ethtool_get_ksettings David Decotigny <ddecotig@gmail.com> - 2016-02-10 01:40 +0100
Re: [PATCH net-next v8 00/19] new ETHTOOL_GSETTINGS/SSETTINGS API Stephen Hemminger <stephen@networkplumber.org> - 2016-02-11 02:00 +0100
Re: [PATCH net-next v8 05/19] net: ethtool: add new ETHTOOL_GSETTINGS/SSETTINGS API Ben Hutchings <ben@decadent.org.uk> - 2016-02-13 02:50 +0100
Re: [PATCH net-next v8 05/19] net: ethtool: add new ETHTOOL_GSETTINGS/SSETTINGS API David Decotigny <ddecotig@gmail.com> - 2016-02-18 21:00 +0100
Page 2 of 2 — ← Prev page 1 [2]
| From | David Decotigny <ddecotig@gmail.com> |
|---|---|
| Date | 2016-02-10 01:40 +0100 |
| Subject | [PATCH net-next v8 15/19] net: bridge: use __ethtool_get_ksettings |
| Message-ID | <r0qZ5-39o-45@gated-at.bofh.it> |
| In reply to | #1330788 |
From: David Decotigny <decot@googlers.com>
Signed-off-by: David Decotigny <decot@googlers.com>
---
net/bridge/br_if.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
index c367b3e..cafe4e6 100644
--- a/net/bridge/br_if.c
+++ b/net/bridge/br_if.c
@@ -36,10 +36,10 @@
*/
static int port_cost(struct net_device *dev)
{
- struct ethtool_cmd ecmd;
+ struct ethtool_ksettings ecmd;
- if (!__ethtool_get_settings(dev, &ecmd)) {
- switch (ethtool_cmd_speed(&ecmd)) {
+ if (!__ethtool_get_ksettings(dev, &ecmd)) {
+ switch (ecmd.parent.speed) {
case SPEED_10000:
return 2;
case SPEED_1000:
--
2.7.0.rc3.207.g0ac5344
[toc] | [prev] | [next] | [standalone]
| From | Stephen Hemminger <stephen@networkplumber.org> |
|---|---|
| Date | 2016-02-11 02:00 +0100 |
| Message-ID | <r0NLY-1gC-17@gated-at.bofh.it> |
| In reply to | #1330788 |
On Tue, 9 Feb 2016 16:29:09 -0800 David Decotigny <ddecotig@gmail.com> wrote: > Along the way, I chose to drop in the new structure the 3 ethtool_cmd > fields marked "deprecated" (transceiver/maxrxpkt/maxtxpkt). They are > still available for old drivers via the (old) ETHTOOL_GSET/SSET API, > but are not available to drivers that switch to new API. Of those 3 > fields, ethtool_cmd::transceiver seems to be still actively used by > several drivers, maybe we should not consider this field deprecated? > The 2 other fields are basically not used. This transition requires > some care in the way old and new ethtool talk to the kernel. Please just fix old drivers. It is perfectly acceptable to break any out of tree drivers.
[toc] | [prev] | [next] | [standalone]
| From | Ben Hutchings <ben@decadent.org.uk> |
|---|---|
| Date | 2016-02-13 02:50 +0100 |
| Subject | Re: [PATCH net-next v8 05/19] net: ethtool: add new ETHTOOL_GSETTINGS/SSETTINGS API |
| Message-ID | <r1xvs-6BF-3@gated-at.bofh.it> |
| In reply to | #1330788 |
[Multipart message — attachments visible in raw view] — view raw
On Tue, 2016-02-09 at 16:29 -0800, David Decotigny wrote: > From: David Decotigny <decot@googlers.com> > > This patch defines a new ETHTOOL_GSETTINGS/SSETTINGS API, handled by > the new get_ksettings/set_ksettings callbacks. This API provides > support for most legacy ethtool_cmd fields, adds support for larger > link mode masks (up to 4064 bits, variable length), and removes > ethtool_cmd deprecated fields (transceiver/maxrxpkt/maxtxpkt). [...] I previously asked you to include 'link' in the command names and structure name. This would clarify that these are now only for link settings and reduce the risk of confusion between old and new commands. However, you didn't reply to that review. Do you have any objection to doing this? Ben. -- Ben Hutchings Sturgeon's Law: Ninety percent of everything is crap.
[toc] | [prev] | [next] | [standalone]
| From | David Decotigny <ddecotig@gmail.com> |
|---|---|
| Date | 2016-02-18 21:00 +0100 |
| Subject | Re: [PATCH net-next v8 05/19] net: ethtool: add new ETHTOOL_GSETTINGS/SSETTINGS API |
| Message-ID | <r3CU3-27a-19@gated-at.bofh.it> |
| In reply to | #1333249 |
Sure, I will send an update:
struct ethtool_link_settings {
__u32 cmd;
__u32 speed;
__u8 duplex;
__u8 port;
__u8 phy_address;
__u8 autoneg;
__u8 mdio_support;
__u8 eth_tp_mdix;
__u8 eth_tp_mdix_ctrl;
__s8 link_mode_masks_nwords;
__u32 reserved[8];
__u32 link_mode_masks[0];
};
(+ same renaming for the ioctl sub-cmds)
that would still replace GSET/SSET/ethtool_cmd.
would that be ok?
Or, just to make sure: would you rather keep GSET/SSET/ethtool_cmd as
now for everything but the link mode masks (that would be marked as
deprecated), and have only a new command G/SLINK_MODES + struct
ethtool_link_mode_support that would only take care of the link mode
masks?
On Fri, Feb 12, 2016 at 5:49 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
> On Tue, 2016-02-09 at 16:29 -0800, David Decotigny wrote:
>> From: David Decotigny <decot@googlers.com>
>>
>> This patch defines a new ETHTOOL_GSETTINGS/SSETTINGS API, handled by
>> the new get_ksettings/set_ksettings callbacks. This API provides
>> support for most legacy ethtool_cmd fields, adds support for larger
>> link mode masks (up to 4064 bits, variable length), and removes
>> ethtool_cmd deprecated fields (transceiver/maxrxpkt/maxtxpkt).
> [...]
>
> I previously asked you to include 'link' in the command names and
> structure name. This would clarify that these are now only for link
> settings and reduce the risk of confusion between old and new commands.
> However, you didn't reply to that review. Do you have any objection to
> doing this?
>
> Ben.
>
> --
> Ben Hutchings
> Sturgeon's Law: Ninety percent of everything is crap.
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | linux.kernel
csiph-web