* Re: [pull request][for-next] Mellanox mlx5 Reorganize core driver directory layout
From: Tom Herbert @ 2017-01-16 21:06 UTC (permalink / raw)
To: Saeed Mahameed
Cc: David Miller, Saeed Mahameed, Doug Ledford, Linux Netdev List,
linux-rdma, Leon Romanovsky
In-Reply-To: <CALzJLG--ZRVk0Zy+6UaGCWbOhki+PZnkmrh9rjojU1ZDm_5Y6w@mail.gmail.com>
On Mon, Jan 16, 2017 at 12:30 PM, Saeed Mahameed
<saeedm@dev.mellanox.co.il> wrote:
> On Sat, Jan 14, 2017 at 12:07 AM, Saeed Mahameed
> <saeedm@dev.mellanox.co.il> wrote:
>> On Fri, Jan 13, 2017 at 7:14 PM, David Miller <davem@davemloft.net> wrote:
>>> From: Saeed Mahameed <saeedm@mellanox.com>
>>> Date: Thu, 12 Jan 2017 19:22:34 +0200
>>>
>>>> This pull request includes one patch from Leon, this patch as described
>>>> below will change the driver directory structure and layout for better,
>>>> logical and modular driver files separation.
>>>>
>>>> This change is important to both rdma and net maintainers in order to
>>>> have smoother management of driver patches for different mlx5 sub modules
>>>> and smoother rdma-next vs. net-next features submissions.
>>>>
>>>> Please find more info below -in the tag commit message-,
>>>> review and let us know if there's any problem.
>>>>
>>>> This change doesn't introduce any conflicts with the current mlx5
>>>> fixes and cleanups posted on 2017-01-10 to net branch, and merge tests
>>>> worked flawlessly with no issues.
>>>>
>>>> This is the last pull request meant for both rdma-next and net-next.
>>>> Once pulled, this will be the base shared code for both trees.
>>>
>>> This is pretty crazy, it will make all bug fix backporting to -stable
>>> a complete nightmare for myself, Doug, various distribution maintainers
>>> and many other people who quietly have to maintain their own trees and
>>> do backporting.
>>>
>>
>> I hear you,
>> But please bear with me here, what if we queue this patch up to -stable ? and we
>> (Mellanox) and specifically our dedicated inbox team, will make sure
>> that this patch
>> will land on the various distributions and for those maintaining their
>> own trees.
>> This patch is really straight forward (rename files) and I already
>> tried to cherry-pick it
>> on older kernels, I only got a couple of conflicts on some of the
>> "#inlcude" lines we've
>> changed, and they are pretty straightforward to fix, we can even avoid
>> this if we decide to
>> not move mlx5 header files in this phase.
>>
>> If this is possible then all trees will be aligned and it will be a
>> win win situation.
>>
>
> Hi Dave,
>
> Any chance you saw my -stable suggestion above ?
> I think it would really close the backporting gap.
>
> Sorry i am bothering you with this topic, but we really desire the new
> structure and
> I never got your feedback on this suggestion, so i would like to hear
> your thoughts.
>
Saeed,
I've already you specific suggestions on your new structure, please
consider your reviewers feedback more carefully. Again, the starting
point for your restructuring should be to separate out the minimum set
of files required to build reasonable driver and then cleanly
compartmentalize the rest of the features to make it easy for your
users to include or not include those in their build. Unless you've
done this I'm not seeing much benefit for this restructuring. Also, I
would rather see this done in one shot then expecting some sort of
evolution over time to the right solution-- as Dave said the
complexity of this driver is to far down the road to do that.
Tom
> Thanks,
> Saeed.
>
>>> I really don't think you can justify this rearrangement based upon the
>>> consequences and how much activity happens in this driver.
>>>
>>
>> Right, but this is not the only justification, I can sum it up to that
>> we would like
>> to lay out the foundation for many years to come for a well designed
>> driver with a modular
>> sub modules break down and scalable infrastructure. We already plan to
>> submit more mlx5
>> independent sub modules - just like mlx5e (en_*) files and mlx5_ib
>> driver- so this was also
>> a reason for us to consider this re-engagement at this stage.
>>
>>> You should have thought long and hard about the layout a long time ago
>>> rather than after the driver has been in the tree for many years.
>>>
>>
>> I had this Idea for the separation before the mlx5 Ethernet
>> submission, but I wasn't the maintainer
>> back then, and i have been itching to submit such patch for long as
>> well, still i don't think
>> it is too late, We (Me and Leon) will keep maintaining this driver for
>> only god knows how many years to come,
>> and the mlx5 drivers are meant to serve at least 3-4 more future HW generations.
>>
>> Long story short, We would like to re-arrange the driver in a way that
>> would serve us (the maintainers) and serve those
>> who are going do develop the future Stack features and the future HW
>> generations over the well designed (Hopefully)
>> mlx5 infrastructure.
>> Keeping it as it is today, will only make the situation worst in the
>> future and it will be really hard to avoid having a spaghetti code
>> in the mlx5 driver. All i want to point out here is that maintaining
>> such a flat subtree is also nightmare.
>>
>> So i am only asking you to reconsider this change and give my -stable
>> suggestion a thought.
>>
>> Thank you.
>> Saeed.
^ permalink raw reply
* [PATCH v3] net/irda: fix lockdep annotation
From: Dmitry Vyukov @ 2017-01-16 21:10 UTC (permalink / raw)
To: davej, samuel, davem; +Cc: glider, andreyknvl, Dmitry Vyukov, netdev
The current annotation uses a global variable as recursion counter.
The variable is not atomic nor protected with a mutex, but mutated
by multiple threads. This causes lockdep bug reports episodically:
BUG: looking up invalid subclass: 4294967295
...
_raw_spin_lock_irqsave_nested+0x120/0x180
hashbin_delete+0x4fe/0x750
__irias_delete_object+0xab/0x170
irias_delete_object+0x5f/0xc0
ircomm_tty_detach_cable+0x1d5/0x3f0
...
Make the hashbin_lock_depth variable atomic to prevent bug reports.
As is this causes "unused variable 'depth'" warning without LOCKDEP.
So also change raw_spin_lock_irqsave_nested() macro to not cause
the warning without LOCKDEP. Similar to what raw_spin_lock_nested()
already does.
Signed-off-by: Dmitry Vyukov <dvyukov@google.com>
Cc: Dave Jones <davej@redhat.com>
Cc: Samuel Ortiz <samuel@sortiz.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Fixes: c7630a4b932af ("[IrDA]: irda lockdep annotation")
---
Changes since v1:
- Added raw_spin_lock_irqsave_nested() change
as 0-DAY bot reported compiler warning without LOCKDEP.
Changes since v2:
- Use ((void)(subclass), (lock)) instead of (void)subclass
to prevent unused variable warning. Now 0-DAY complaints
"error: void value not ignored as it ought to be".
My compiler does not produce warning with W=1 either way,
but the comma trick is what already used in raw_spin_lock_nested().
---
include/linux/spinlock.h | 2 +-
net/irda/irqueue.c | 12 +++++++-----
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/include/linux/spinlock.h b/include/linux/spinlock.h
index 47dd0cebd204..beeb5a39bd8b 100644
--- a/include/linux/spinlock.h
+++ b/include/linux/spinlock.h
@@ -218,7 +218,7 @@ static inline void do_raw_spin_unlock(raw_spinlock_t *lock) __releases(lock)
#define raw_spin_lock_irqsave_nested(lock, flags, subclass) \
do { \
typecheck(unsigned long, flags); \
- flags = _raw_spin_lock_irqsave(lock); \
+ flags = _raw_spin_lock_irqsave(((void)(subclass), (lock))); \
} while (0)
#endif
diff --git a/net/irda/irqueue.c b/net/irda/irqueue.c
index acbe61c7e683..b9fd74e6ca99 100644
--- a/net/irda/irqueue.c
+++ b/net/irda/irqueue.c
@@ -384,21 +384,23 @@ EXPORT_SYMBOL(hashbin_new);
* just supply kfree, which should take care of the job.
*/
#ifdef CONFIG_LOCKDEP
-static int hashbin_lock_depth = 0;
+static atomic_t hashbin_lock_depth = ATOMIC_INIT(0);
#endif
int hashbin_delete( hashbin_t* hashbin, FREE_FUNC free_func)
{
irda_queue_t* queue;
unsigned long flags = 0;
- int i;
+ int i, depth = 0;
IRDA_ASSERT(hashbin != NULL, return -1;);
IRDA_ASSERT(hashbin->magic == HB_MAGIC, return -1;);
/* Synchronize */
if ( hashbin->hb_type & HB_LOCK ) {
- spin_lock_irqsave_nested(&hashbin->hb_spinlock, flags,
- hashbin_lock_depth++);
+#ifdef CONFIG_LOCKDEP
+ depth = atomic_inc_return(&hashbin_lock_depth) - 1;
+#endif
+ spin_lock_irqsave_nested(&hashbin->hb_spinlock, flags, depth);
}
/*
@@ -423,7 +425,7 @@ int hashbin_delete( hashbin_t* hashbin, FREE_FUNC free_func)
if ( hashbin->hb_type & HB_LOCK) {
spin_unlock_irqrestore(&hashbin->hb_spinlock, flags);
#ifdef CONFIG_LOCKDEP
- hashbin_lock_depth--;
+ atomic_dec(&hashbin_lock_depth);
#endif
}
--
2.11.0.483.g087da7b7c-goog
^ permalink raw reply related
* Re: [PATCH v2] net/irda: fix lockdep annotation
From: Dmitry Vyukov @ 2017-01-16 21:11 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, Dave Jones, Samuel Ortiz, David Miller,
Alexander Potapenko, andreyknvl, netdev
In-Reply-To: <201701170149.G5mmkfWa%fengguang.wu@intel.com>
On Mon, Jan 16, 2017 at 7:09 PM, kbuild test robot <lkp@intel.com> wrote:
> Hi Dmitry,
>
> [auto build test ERROR on tip/locking/core]
> [also build test ERROR on v4.10-rc4 next-20170116]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/Dmitry-Vyukov/net-irda-fix-lockdep-annotation/20170117-001737
> config: i386-defconfig (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All error/warnings (new ones prefixed by >>):
>
> In file included from include/linux/mmzone.h:7:0,
> from include/linux/gfp.h:5,
> from include/linux/slab.h:14,
> from drivers/gpu/drm/i915/i915_sw_fence.c:10:
> drivers/gpu/drm/i915/i915_sw_fence.c: In function '__i915_sw_fence_wake_up_all':
>>> include/linux/spinlock.h:217:3: error: void value not ignored as it ought to be
> (void)subclass; \
>
>>> include/linux/spinlock.h:335:2: note: in expansion of macro 'raw_spin_lock_irqsave_nested'
> raw_spin_lock_irqsave_nested(spinlock_check(lock), flags, subclass); \
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> drivers/gpu/drm/i915/i915_sw_fence.c:68:2: note: in expansion of macro 'spin_lock_irqsave_nested'
> spin_lock_irqsave_nested(&x->lock, flags, 1 + !!continuation);
> ^~~~~~~~~~~~~~~~~~~~~~~~
Mailed v3.
> vim +217 include/linux/spinlock.h
>
> 211 typecheck(unsigned long, flags); \
> 212 flags = _raw_spin_lock_irqsave_nested(lock, subclass); \
> 213 } while (0)
> 214 #else
> 215 #define raw_spin_lock_irqsave_nested(lock, flags, subclass) \
> 216 do { \
> > 217 (void)subclass; \
> 218 typecheck(unsigned long, flags); \
> 219 flags = _raw_spin_lock_irqsave(lock); \
> 220 } while (0)
> 221 #endif
> 222
> 223 #else
> 224
> 225 #define raw_spin_lock_irqsave(lock, flags) \
> 226 do { \
> 227 typecheck(unsigned long, flags); \
> 228 _raw_spin_lock_irqsave(lock, flags); \
> 229 } while (0)
> 230
> 231 #define raw_spin_lock_irqsave_nested(lock, flags, subclass) \
> 232 raw_spin_lock_irqsave(lock, flags)
> 233
> 234 #endif
> 235
> 236 #define raw_spin_lock_irq(lock) _raw_spin_lock_irq(lock)
> 237 #define raw_spin_lock_bh(lock) _raw_spin_lock_bh(lock)
> 238 #define raw_spin_unlock(lock) _raw_spin_unlock(lock)
> 239 #define raw_spin_unlock_irq(lock) _raw_spin_unlock_irq(lock)
> 240
> 241 #define raw_spin_unlock_irqrestore(lock, flags) \
> 242 do { \
> 243 typecheck(unsigned long, flags); \
> 244 _raw_spin_unlock_irqrestore(lock, flags); \
> 245 } while (0)
> 246 #define raw_spin_unlock_bh(lock) _raw_spin_unlock_bh(lock)
> 247
> 248 #define raw_spin_trylock_bh(lock) \
> 249 __cond_lock(lock, _raw_spin_trylock_bh(lock))
> 250
> 251 #define raw_spin_trylock_irq(lock) \
> 252 ({ \
> 253 local_irq_disable(); \
> 254 raw_spin_trylock(lock) ? \
> 255 1 : ({ local_irq_enable(); 0; }); \
> 256 })
> 257
> 258 #define raw_spin_trylock_irqsave(lock, flags) \
> 259 ({ \
> 260 local_irq_save(flags); \
> 261 raw_spin_trylock(lock) ? \
> 262 1 : ({ local_irq_restore(flags); 0; }); \
> 263 })
> 264
> 265 /**
> 266 * raw_spin_can_lock - would raw_spin_trylock() succeed?
> 267 * @lock: the spinlock in question.
> 268 */
> 269 #define raw_spin_can_lock(lock) (!raw_spin_is_locked(lock))
> 270
> 271 /* Include rwlock functions */
> 272 #include <linux/rwlock.h>
> 273
> 274 /*
> 275 * Pull the _spin_*()/_read_*()/_write_*() functions/declarations:
> 276 */
> 277 #if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_SPINLOCK)
> 278 # include <linux/spinlock_api_smp.h>
> 279 #else
> 280 # include <linux/spinlock_api_up.h>
> 281 #endif
> 282
> 283 /*
> 284 * Map the spin_lock functions to the raw variants for PREEMPT_RT=n
> 285 */
> 286
> 287 static __always_inline raw_spinlock_t *spinlock_check(spinlock_t *lock)
> 288 {
> 289 return &lock->rlock;
> 290 }
> 291
> 292 #define spin_lock_init(_lock) \
> 293 do { \
> 294 spinlock_check(_lock); \
> 295 raw_spin_lock_init(&(_lock)->rlock); \
> 296 } while (0)
> 297
> 298 static __always_inline void spin_lock(spinlock_t *lock)
> 299 {
> 300 raw_spin_lock(&lock->rlock);
> 301 }
> 302
> 303 static __always_inline void spin_lock_bh(spinlock_t *lock)
> 304 {
> 305 raw_spin_lock_bh(&lock->rlock);
> 306 }
> 307
> 308 static __always_inline int spin_trylock(spinlock_t *lock)
> 309 {
> 310 return raw_spin_trylock(&lock->rlock);
> 311 }
> 312
> 313 #define spin_lock_nested(lock, subclass) \
> 314 do { \
> 315 raw_spin_lock_nested(spinlock_check(lock), subclass); \
> 316 } while (0)
> 317
> 318 #define spin_lock_nest_lock(lock, nest_lock) \
> 319 do { \
> 320 raw_spin_lock_nest_lock(spinlock_check(lock), nest_lock); \
> 321 } while (0)
> 322
> 323 static __always_inline void spin_lock_irq(spinlock_t *lock)
> 324 {
> 325 raw_spin_lock_irq(&lock->rlock);
> 326 }
> 327
> 328 #define spin_lock_irqsave(lock, flags) \
> 329 do { \
> 330 raw_spin_lock_irqsave(spinlock_check(lock), flags); \
> 331 } while (0)
> 332
> 333 #define spin_lock_irqsave_nested(lock, flags, subclass) \
> 334 do { \
> > 335 raw_spin_lock_irqsave_nested(spinlock_check(lock), flags, subclass); \
> 336 } while (0)
> 337
> 338 static __always_inline void spin_unlock(spinlock_t *lock)
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: [PATCH] net: marvell: skge: use new api ethtool_{get|set}_link_ksettings
From: Philippe Reynes @ 2017-01-16 21:27 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, mlindner, netdev, linux-kernel
In-Reply-To: <20170116095003.6998b773@xeon-e3>
Hi Stephen,
On 1/16/17, Stephen Hemminger <stephen@networkplumber.org> wrote:
> On Mon, 16 Jan 2017 12:36:17 -0500 (EST)
> David Miller <davem@davemloft.net> wrote:
>
>> From: Stephen Hemminger <stephen@networkplumber.org>
>> Date: Mon, 16 Jan 2017 09:29:51 -0800
>>
>> > On Sat, 14 Jan 2017 13:08:28 +0100
>> > Philippe Reynes <tremyfr@gmail.com> wrote:
>> >
>> >> The ethtool api {get|set}_settings is deprecated.
>> >> We move this driver to new api {get|set}_link_ksettings.
>> >>
>> >> The callback set_link_ksettings no longer update the value
>> >> of advertising, as the struct ethtool_link_ksettings is
>> >> defined as const.
>> >>
>> >> Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
>> >
>> > Did you test this on real hardware?
>>
>> Philippe probably doesn't have physical access to most of the
>> drivers he is converting.
>>
>> But, he is the only person working on converting all of the drivers,
>> and therefore when the change looks straightforward I am going to
>> reward his work and effort by applying his changes and hope there
>> isn't any fallout.
>>
>> Those who really care can test his patches and give a Tested-by:
>>
>> Thanks.
>
> Yes, it looks mechanical and should be applied. There are lots of pieces of
> old hardware that no developer is running, and if we required full test
> suite runs
> on all drivers, then no refactoring would ever be possible.
>
> My preference is to always add commit note that the patch was compile
> tested only so that if someone has a problem with real hardware then they
> know
> what to suspect.
David is right, I don't have the hardware to test all drivers.
I haven't added a little note on all commit, because I was
thinking it would be a lot of noise. But if you prefer (and
David agrees), I'll add a note on all the following patches.
Btw, thanks David for applying my patches.
Philippe
^ permalink raw reply
* Re: [PATCH net-next 3/9] net/mlx4_core: Set EQ affinity hint to local NUMA CPUs
From: Or Gerlitz @ 2017-01-16 21:44 UTC (permalink / raw)
To: Tariq Toukan, Daniel Jurgens
Cc: David S. Miller, Linux Netdev List, Eran Ben Elisha
In-Reply-To: <1484587805-12666-4-git-send-email-tariqt@mellanox.com>
On Mon, Jan 16, 2017 at 7:29 PM, Tariq Toukan <tariqt@mellanox.com> wrote:
> From: Daniel Jurgens <danielj@mellanox.com>
>
> Use CPUs on the close NUMA when setting the EQ affinity hints.
Dan, are we sure there are no down-sides for always doing this? this
code is probably there for many years and we're introducing here new
behaviour to potentially to many Ms installs when they get distro
update that includes this patch.
^ permalink raw reply
* Re: [patch net-next] stmmac: indent an if statement
From: Julia Lawall @ 2017-01-16 21:46 UTC (permalink / raw)
To: Dan Carpenter
Cc: David Miller, peppe.cavallaro, Joao.Pinto, alexandre.torgue,
netdev, linux-kernel, kernel-janitors
In-Reply-To: <20170116093954.GB4104@mwanda>
On Mon, 16 Jan 2017, Dan Carpenter wrote:
> On Mon, Jan 16, 2017 at 12:19:24PM +0300, Dan Carpenter wrote:
> > On Sun, Jan 15, 2017 at 10:14:38PM -0500, David Miller wrote:
> > > From: Dan Carpenter <dan.carpenter@oracle.com>
> > > Date: Thu, 12 Jan 2017 21:46:32 +0300
> > >
> > > > The break statement should be indented one more tab.
> > > >
> > > > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> > >
> > > Applied, but like Julia I think we might have a missing of_node_put()
> > > here.
> >
> > Of course, sorry for dropping the ball on this. I'll send a patch for
> > that.
> >
>
> Actually, I've looked at it some more and I think this function is OK.
> We're supposed to do an of_node_put() later... I can't find where that
> happens, but presumably that's because I don't know stmmac well. This
> code here, though, is fine.
Why do you think it is fine? Does anyone in the calling context know
which child would have caused the break? An extra put is only needed on
that one. Is there a guarantee that the break is always taken?
julia
^ permalink raw reply
* [PATCH v2] net: marvell: skge: use new api ethtool_{get|set}_link_ksettings
From: Philippe Reynes @ 2017-01-16 21:46 UTC (permalink / raw)
To: mlindner, stephen, davem; +Cc: netdev, linux-kernel, Philippe Reynes
The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.
The callback set_link_ksettings no longer update the value
of advertising, as the struct ethtool_link_ksettings is
defined as const.
As I don't have the hardware, I'd be very pleased if
someone may test this patch.
Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
---
Changelog:
v2:
- update the commit log with a note to explain that this code
was not tested on hardware (feedback from Stephen Hemminger)
drivers/net/ethernet/marvell/skge.c | 63 ++++++++++++++++++++--------------
1 files changed, 37 insertions(+), 26 deletions(-)
diff --git a/drivers/net/ethernet/marvell/skge.c b/drivers/net/ethernet/marvell/skge.c
index 9146a51..81106b7 100644
--- a/drivers/net/ethernet/marvell/skge.c
+++ b/drivers/net/ethernet/marvell/skge.c
@@ -300,65 +300,76 @@ static u32 skge_supported_modes(const struct skge_hw *hw)
return supported;
}
-static int skge_get_settings(struct net_device *dev,
- struct ethtool_cmd *ecmd)
+static int skge_get_link_ksettings(struct net_device *dev,
+ struct ethtool_link_ksettings *cmd)
{
struct skge_port *skge = netdev_priv(dev);
struct skge_hw *hw = skge->hw;
+ u32 supported, advertising;
- ecmd->transceiver = XCVR_INTERNAL;
- ecmd->supported = skge_supported_modes(hw);
+ supported = skge_supported_modes(hw);
if (hw->copper) {
- ecmd->port = PORT_TP;
- ecmd->phy_address = hw->phy_addr;
+ cmd->base.port = PORT_TP;
+ cmd->base.phy_address = hw->phy_addr;
} else
- ecmd->port = PORT_FIBRE;
+ cmd->base.port = PORT_FIBRE;
+
+ advertising = skge->advertising;
+ cmd->base.autoneg = skge->autoneg;
+ cmd->base.speed = skge->speed;
+ cmd->base.duplex = skge->duplex;
+
+ ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.supported,
+ supported);
+ ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.advertising,
+ advertising);
- ecmd->advertising = skge->advertising;
- ecmd->autoneg = skge->autoneg;
- ethtool_cmd_speed_set(ecmd, skge->speed);
- ecmd->duplex = skge->duplex;
return 0;
}
-static int skge_set_settings(struct net_device *dev, struct ethtool_cmd *ecmd)
+static int skge_set_link_ksettings(struct net_device *dev,
+ const struct ethtool_link_ksettings *cmd)
{
struct skge_port *skge = netdev_priv(dev);
const struct skge_hw *hw = skge->hw;
u32 supported = skge_supported_modes(hw);
int err = 0;
+ u32 advertising;
+
+ ethtool_convert_link_mode_to_legacy_u32(&advertising,
+ cmd->link_modes.advertising);
- if (ecmd->autoneg == AUTONEG_ENABLE) {
- ecmd->advertising = supported;
+ if (cmd->base.autoneg == AUTONEG_ENABLE) {
+ advertising = supported;
skge->duplex = -1;
skge->speed = -1;
} else {
u32 setting;
- u32 speed = ethtool_cmd_speed(ecmd);
+ u32 speed = cmd->base.speed;
switch (speed) {
case SPEED_1000:
- if (ecmd->duplex == DUPLEX_FULL)
+ if (cmd->base.duplex == DUPLEX_FULL)
setting = SUPPORTED_1000baseT_Full;
- else if (ecmd->duplex == DUPLEX_HALF)
+ else if (cmd->base.duplex == DUPLEX_HALF)
setting = SUPPORTED_1000baseT_Half;
else
return -EINVAL;
break;
case SPEED_100:
- if (ecmd->duplex == DUPLEX_FULL)
+ if (cmd->base.duplex == DUPLEX_FULL)
setting = SUPPORTED_100baseT_Full;
- else if (ecmd->duplex == DUPLEX_HALF)
+ else if (cmd->base.duplex == DUPLEX_HALF)
setting = SUPPORTED_100baseT_Half;
else
return -EINVAL;
break;
case SPEED_10:
- if (ecmd->duplex == DUPLEX_FULL)
+ if (cmd->base.duplex == DUPLEX_FULL)
setting = SUPPORTED_10baseT_Full;
- else if (ecmd->duplex == DUPLEX_HALF)
+ else if (cmd->base.duplex == DUPLEX_HALF)
setting = SUPPORTED_10baseT_Half;
else
return -EINVAL;
@@ -371,11 +382,11 @@ static int skge_set_settings(struct net_device *dev, struct ethtool_cmd *ecmd)
return -EINVAL;
skge->speed = speed;
- skge->duplex = ecmd->duplex;
+ skge->duplex = cmd->base.duplex;
}
- skge->autoneg = ecmd->autoneg;
- skge->advertising = ecmd->advertising;
+ skge->autoneg = cmd->base.autoneg;
+ skge->advertising = advertising;
if (netif_running(dev)) {
skge_down(dev);
@@ -875,8 +886,6 @@ static int skge_set_eeprom(struct net_device *dev, struct ethtool_eeprom *eeprom
}
static const struct ethtool_ops skge_ethtool_ops = {
- .get_settings = skge_get_settings,
- .set_settings = skge_set_settings,
.get_drvinfo = skge_get_drvinfo,
.get_regs_len = skge_get_regs_len,
.get_regs = skge_get_regs,
@@ -899,6 +908,8 @@ static int skge_set_eeprom(struct net_device *dev, struct ethtool_eeprom *eeprom
.set_phys_id = skge_set_phys_id,
.get_sset_count = skge_get_sset_count,
.get_ethtool_stats = skge_get_ethtool_stats,
+ .get_link_ksettings = skge_get_link_ksettings,
+ .set_link_ksettings = skge_set_link_ksettings,
};
/*
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH 1/2] qed: Add support for hardware offloaded FCoE.
From: Chad Dupuis @ 2017-01-16 21:47 UTC (permalink / raw)
To: martin.petersen
Cc: linux-scsi, fcoe-devel, netdev, yuval.mintz,
QLogic-Storage-Upstream
In-Reply-To: <1484596437-27637-2-git-send-email-chad.dupuis@cavium.com>
I forgot to add netdev-next to the subject line. Is a repost needed here?
On Mon, 16 Jan 2017, 7:53pm -0000, Dupuis, Chad wrote:
> From: Arun Easi <arun.easi@qlogic.com>
>
> This adds the backbone required for the various HW initalizations
> which are necessary for the FCoE driver (qedf) for QLogic FastLinQ
> 4xxxx line of adapters - FW notification, resource initializations, etc.
>
> Signed-off-by: Arun Easi <arun.easi@cavium.com>
> Signed-off-by: Yuval Mintz <yuval.mintz@cavium.com>
> ---
> drivers/net/ethernet/qlogic/Kconfig | 3 +
> drivers/net/ethernet/qlogic/qed/Makefile | 1 +
> drivers/net/ethernet/qlogic/qed/qed.h | 11 +
> drivers/net/ethernet/qlogic/qed/qed_cxt.c | 98 ++-
> drivers/net/ethernet/qlogic/qed/qed_cxt.h | 3 +
> drivers/net/ethernet/qlogic/qed/qed_dcbx.c | 11 +
> drivers/net/ethernet/qlogic/qed/qed_dcbx.h | 1 +
> drivers/net/ethernet/qlogic/qed/qed_dev.c | 205 ++++-
> drivers/net/ethernet/qlogic/qed/qed_dev_api.h | 42 +
> drivers/net/ethernet/qlogic/qed/qed_fcoe.c | 990 ++++++++++++++++++++++
> drivers/net/ethernet/qlogic/qed/qed_fcoe.h | 52 ++
> drivers/net/ethernet/qlogic/qed/qed_hsi.h | 781 ++++++++++++++++-
> drivers/net/ethernet/qlogic/qed/qed_hw.c | 3 +
> drivers/net/ethernet/qlogic/qed/qed_ll2.c | 25 +
> drivers/net/ethernet/qlogic/qed/qed_ll2.h | 2 +-
> drivers/net/ethernet/qlogic/qed/qed_main.c | 7 +
> drivers/net/ethernet/qlogic/qed/qed_mcp.c | 3 +
> drivers/net/ethernet/qlogic/qed/qed_mcp.h | 1 +
> drivers/net/ethernet/qlogic/qed/qed_reg_addr.h | 8 +
> drivers/net/ethernet/qlogic/qed/qed_sp.h | 4 +
> drivers/net/ethernet/qlogic/qed/qed_sp_commands.c | 3 +
> include/linux/qed/common_hsi.h | 10 +-
> include/linux/qed/fcoe_common.h | 715 ++++++++++++++++
> include/linux/qed/qed_fcoe_if.h | 145 ++++
> include/linux/qed/qed_if.h | 39 +
> 25 files changed, 3152 insertions(+), 11 deletions(-)
> create mode 100644 drivers/net/ethernet/qlogic/qed/qed_fcoe.c
> create mode 100644 drivers/net/ethernet/qlogic/qed/qed_fcoe.h
> create mode 100644 include/linux/qed/fcoe_common.h
> create mode 100644 include/linux/qed/qed_fcoe_if.h
>
^ permalink raw reply
* Re: [PATCH net-next 6/9] net/mlx4_en: Adding support of turning off link autonegotiation via ethtool
From: Or Gerlitz @ 2017-01-16 21:48 UTC (permalink / raw)
To: Tariq Toukan, Ariel Levkovich
Cc: David S. Miller, Linux Netdev List, Eran Ben Elisha
In-Reply-To: <1484587805-12666-7-git-send-email-tariqt@mellanox.com>
On Mon, Jan 16, 2017 at 7:30 PM, Tariq Toukan <tariqt@mellanox.com> wrote:
0644
> --- a/include/linux/mlx4/device.h
> +++ b/include/linux/mlx4/device.h
> @@ -1539,8 +1539,13 @@ enum mlx4_ptys_proto {
> MLX4_PTYS_EN = 1<<2,
> };
>
> +enum mlx4_ptys_flags {
> + MLX4_PTYS_AN_DISABLE_CAP = 1 << 5,
> + MLX4_PTYS_AN_DISABLE_ADMIN = 1 << 6,
> +};
> +
> struct mlx4_ptys_reg {
> - u8 resrvd1;
> + u8 flags;
> u8 local_port;
> u8 resrvd2;
> u8 proto_mask;
Hi Ariel,
I didn't see any new dev cap bit, what happens with FW version which
don't support this, is the result well defined? what is it?
Or.
^ permalink raw reply
* Re: [PATCH] net: add regs attribute to phy device for user diagnose
From: David Miller @ 2017-01-16 21:54 UTC (permalink / raw)
To: f.fainelli; +Cc: cugyly, andrew, netdev, Linyu.Yuan
In-Reply-To: <cf3e3125-582f-8b91-9c23-05dbdd2c6d24@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Mon, 16 Jan 2017 12:22:16 -0800
> On 01/16/2017 04:59 AM, yuan linyu wrote:
>> On 日, 2017-01-15 at 18:21 +0100, Andrew Lunn wrote:
>>> On Sun, Jan 15, 2017 at 09:51:03AM +0800, yuan linyu wrote:
>>>>
>>>> I hope user/developer can read this attribute file "regs" to do
>>>> a full check of all registers value, and they can write any register
>>>> inside PHY through this file.
>>> Since this is intended for debug, it should not be sysfs, but debugfs.
>> agree,
>>> However, in general, Linux does not allow user space to peek and poke
>>> device registers. Can you point me at examples where i can do the same
>>> to my GPU? SATA controller? Ethernet controller, I2C temperature
>>> sensor? Any device?
>> we can read registers of ethernet controller(memory register accessed) through devmem or ethtool
>
> So why not add support in ethtool for reading PHY registers if you need
> it? There are handful of PHY "things" in ethtool, such as reading
> counters, configuring downshift etc., adding support for dumping
> registers does not sound out of space.
Agreed.
^ permalink raw reply
* Re: [PATCH net-next 3/9] net/mlx4_core: Set EQ affinity hint to local NUMA CPUs
From: Daniel Jurgens @ 2017-01-16 21:54 UTC (permalink / raw)
To: Or Gerlitz, Tariq Toukan
Cc: David S. Miller, Linux Netdev List, Eran Ben Elisha
In-Reply-To: <CAJ3xEMiGQHV1Qc0aW43SJaNO7X5TRLdYRaZgEiA6099vbBAAXw@mail.gmail.com>
On 1/16/2017 3:44 PM, Or Gerlitz wrote:
> On Mon, Jan 16, 2017 at 7:29 PM, Tariq Toukan <tariqt@mellanox.com> wrote:
>> From: Daniel Jurgens <danielj@mellanox.com>
>>
>> Use CPUs on the close NUMA when setting the EQ affinity hints.
> Dan, are we sure there are no down-sides for always doing this? this
> code is probably there for many years and we're introducing here new
> behaviour to potentially to many Ms installs when they get distro
> update that includes this patch.
>
I don't see a downside, this just favors using the node local CPUs before others. I don't understand your 2nd sentence there. "Ms installs"?
^ permalink raw reply
* Re: [net-next 0/3] tipc: improve interaction socket-link
From: David Miller @ 2017-01-16 21:54 UTC (permalink / raw)
To: jon.maloy
Cc: netdev, viro, parthasarathy.bhuvaragan, ying.xue, maloy,
tipc-discussion
In-Reply-To: <A2BAEFC30C8FD34388F02C9B3121859D225F44DE@eusaamb103.ericsson.se>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Mon, 16 Jan 2017 20:35:08 +0000
>
>
>> -----Original Message-----
>> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
>> On Behalf Of David Miller
>> Sent: Monday, 16 January, 2017 14:45
>> To: Jon Maloy <jon.maloy@ericsson.com>
>> Cc: netdev@vger.kernel.org; viro@zeniv.linux.org.uk; Parthasarathy Bhuvaragan
>> <parthasarathy.bhuvaragan@ericsson.com>; Ying Xue
>> <ying.xue@windriver.com>; maloy@donjonn.com; tipc-
>> discussion@lists.sourceforge.net
>> Subject: Re: [net-next 0/3] tipc: improve interaction socket-link
>>
>> From: Jon Maloy <jon.maloy@ericsson.com>
>> Date: Tue, 3 Jan 2017 10:26:45 -0500
>>
>> > We fix a very real starvation problem that may occur when a link
>> > encounters send buffer congestion. At the same time we make the
>> > interaction between the socket and link layer simpler and more
>> > consistent.
>>
>> This doesn't apply to net-next, also the Date in your emails is 10 days
>> in the past. What's going on here?
>
> I don't know. This series was sent in on Jan 3rd, and applied by you the same day. Maybe the mail server decided to send you a duplicate?
If you look in the headers, they have "Received-by: " fields with
January 13th in the date. So something pushed them out again.
Really strange...
^ permalink raw reply
* Re: [PATCH V2] audit: log 32-bit socketcalls
From: David Miller @ 2017-01-16 21:55 UTC (permalink / raw)
To: paul; +Cc: rgb, netdev, linux-kernel, linux-audit
In-Reply-To: <CAHC9VhQwVOQ+-iZ1iC-efVvCUadMCdRJS60wqgUQWgExL51yEw@mail.gmail.com>
From: Paul Moore <paul@paul-moore.com>
Date: Mon, 16 Jan 2017 15:38:33 -0500
> David, assuming Richard makes your requested changes, any objection if
> I merge this via the audit tree instead of the netdev tree? It's a
> bit easier for us from a testing perspective this way ...
No objection.
^ permalink raw reply
* Re: [patch net-next] stmmac: indent an if statement
From: Dan Carpenter @ 2017-01-16 21:56 UTC (permalink / raw)
To: Julia Lawall
Cc: David Miller, peppe.cavallaro, Joao.Pinto, alexandre.torgue,
netdev, linux-kernel, kernel-janitors
In-Reply-To: <alpine.DEB.2.20.1701162240100.2031@hadrien>
On Mon, Jan 16, 2017 at 10:46:22PM +0100, Julia Lawall wrote:
>
>
> On Mon, 16 Jan 2017, Dan Carpenter wrote:
>
> > On Mon, Jan 16, 2017 at 12:19:24PM +0300, Dan Carpenter wrote:
> > > On Sun, Jan 15, 2017 at 10:14:38PM -0500, David Miller wrote:
> > > > From: Dan Carpenter <dan.carpenter@oracle.com>
> > > > Date: Thu, 12 Jan 2017 21:46:32 +0300
> > > >
> > > > > The break statement should be indented one more tab.
> > > > >
> > > > > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> > > >
> > > > Applied, but like Julia I think we might have a missing of_node_put()
> > > > here.
> > >
> > > Of course, sorry for dropping the ball on this. I'll send a patch for
> > > that.
> > >
> >
> > Actually, I've looked at it some more and I think this function is OK.
> > We're supposed to do an of_node_put() later... I can't find where that
> > happens, but presumably that's because I don't know stmmac well. This
> > code here, though, is fine.
>
> Why do you think it is fine? Does anyone in the calling context know
> which child would have caused the break?
Yeah. It's saved in plat->mdio_node and we expect to be holding on
either path through the function.
(It would be better if one of the stmmac people were responding here
insead of a random fix the indenting weenie like myself.)
regards,
dan caprenter
^ permalink raw reply
* Re: [PATCH 1/2] qed: Add support for hardware offloaded FCoE.
From: David Miller @ 2017-01-16 21:56 UTC (permalink / raw)
To: chad.dupuis
Cc: martin.petersen, linux-scsi, fcoe-devel, netdev, yuval.mintz,
QLogic-Storage-Upstream
In-Reply-To: <alpine.OSX.2.00.1701161633290.2060@administrators-macbook-pro.local>
From: Chad Dupuis <chad.dupuis@cavium.com>
Date: Mon, 16 Jan 2017 16:47:52 -0500
> I forgot to add netdev-next to the subject line. Is a repost needed
> here?
Not this time, no.
^ permalink raw reply
* Re: [PATCH net-next 3/9] net/mlx4_core: Set EQ affinity hint to local NUMA CPUs
From: David Miller @ 2017-01-16 21:57 UTC (permalink / raw)
To: danielj; +Cc: gerlitz.or, tariqt, netdev, eranbe
In-Reply-To: <VI1PR0501MB2429F11A34431293F2D0C327C47D0@VI1PR0501MB2429.eurprd05.prod.outlook.com>
From: Daniel Jurgens <danielj@mellanox.com>
Date: Mon, 16 Jan 2017 21:54:36 +0000
> I don't understand your 2nd sentence there. "Ms installs"?
I think he meant "Mellanox's installs", meaning installations of Linux
using Mellanox hardware. At least that's how I read it.
^ permalink raw reply
* Re: [PATCH net-next 3/9] net/mlx4_core: Set EQ affinity hint to local NUMA CPUs
From: Or Gerlitz @ 2017-01-16 21:59 UTC (permalink / raw)
To: Daniel Jurgens
Cc: Tariq Toukan, David S. Miller, Linux Netdev List, Eran Ben Elisha
In-Reply-To: <VI1PR0501MB2429F11A34431293F2D0C327C47D0@VI1PR0501MB2429.eurprd05.prod.outlook.com>
On Mon, Jan 16, 2017 at 11:54 PM, Daniel Jurgens <danielj@mellanox.com> wrote:
> On 1/16/2017 3:44 PM, Or Gerlitz wrote:
>> On Mon, Jan 16, 2017 at 7:29 PM, Tariq Toukan <tariqt@mellanox.com> wrote:
>>> From: Daniel Jurgens <danielj@mellanox.com>
>>>
>>> Use CPUs on the close NUMA when setting the EQ affinity hints.
>> Dan, are we sure there are no down-sides for always doing this? this
>> code is probably there for many years and we're introducing here new
>> behaviour to potentially to many Ms installs when they get distro
>> update that includes this patch.
> I don't see a downside, this just favors using the node local CPUs before others.
OK, so this just favors before others and not limits (not in front of
the code now)? would be good to improve the change log and make this
clear.
> I don't understand your 2nd sentence there. "Ms installs"?
Millions of installs that run Linux driver.
^ permalink raw reply
* Re: [patch net-next] stmmac: indent an if statement
From: David Miller @ 2017-01-16 22:00 UTC (permalink / raw)
To: dan.carpenter
Cc: julia.lawall, peppe.cavallaro, Joao.Pinto, alexandre.torgue,
netdev, linux-kernel, kernel-janitors
In-Reply-To: <20170116215615.GG4104@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Tue, 17 Jan 2017 00:56:15 +0300
> (It would be better if one of the stmmac people were responding here
> insead of a random fix the indenting weenie like myself.)
They are all too busy trying to rename the driver, because that's so
much more important.
^ permalink raw reply
* Re: [patch net-next] stmmac: indent an if statement
From: Julia Lawall @ 2017-01-16 22:10 UTC (permalink / raw)
To: Dan Carpenter
Cc: David Miller, peppe.cavallaro, Joao.Pinto, alexandre.torgue,
netdev, linux-kernel, kernel-janitors
In-Reply-To: <20170116215615.GG4104@mwanda>
On Tue, 17 Jan 2017, Dan Carpenter wrote:
> On Mon, Jan 16, 2017 at 10:46:22PM +0100, Julia Lawall wrote:
> >
> >
> > On Mon, 16 Jan 2017, Dan Carpenter wrote:
> >
> > > On Mon, Jan 16, 2017 at 12:19:24PM +0300, Dan Carpenter wrote:
> > > > On Sun, Jan 15, 2017 at 10:14:38PM -0500, David Miller wrote:
> > > > > From: Dan Carpenter <dan.carpenter@oracle.com>
> > > > > Date: Thu, 12 Jan 2017 21:46:32 +0300
> > > > >
> > > > > > The break statement should be indented one more tab.
> > > > > >
> > > > > > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> > > > >
> > > > > Applied, but like Julia I think we might have a missing of_node_put()
> > > > > here.
> > > >
> > > > Of course, sorry for dropping the ball on this. I'll send a patch for
> > > > that.
> > > >
> > >
> > > Actually, I've looked at it some more and I think this function is OK.
> > > We're supposed to do an of_node_put() later... I can't find where that
> > > happens, but presumably that's because I don't know stmmac well. This
> > > code here, though, is fine.
> >
> > Why do you think it is fine? Does anyone in the calling context know
> > which child would have caused the break?
>
> Yeah. It's saved in plat->mdio_node and we expect to be holding on
> either path through the function.
>
> (It would be better if one of the stmmac people were responding here
> insead of a random fix the indenting weenie like myself.)
OK, I agree that there should not be an of_node_put with the break.
Perhaps there should be an of_node_put on plat->mdio_node in
stmmac_remove_config_dt, like there is an of_node_put on plat->phy_node.
But it would certainly be helpful to hear from someone who knows the code
better.
julia
^ permalink raw reply
* Re: [PATCH net-next 3/9] net/mlx4_core: Set EQ affinity hint to local NUMA CPUs
From: Daniel Jurgens @ 2017-01-16 22:21 UTC (permalink / raw)
To: Or Gerlitz
Cc: Tariq Toukan, David S. Miller, Linux Netdev List, Eran Ben Elisha
In-Reply-To: <CAJ3xEMjGv8xm7vOgASd0CvpS9uQFLv8tT_n7aqsuoB7eTUAZUg@mail.gmail.com>
On 1/16/2017 3:59 PM, Or Gerlitz wrote:
> On Mon, Jan 16, 2017 at 11:54 PM, Daniel Jurgens <danielj@mellanox.com> wrote:
>> On 1/16/2017 3:44 PM, Or Gerlitz wrote:
>>> On Mon, Jan 16, 2017 at 7:29 PM, Tariq Toukan <tariqt@mellanox.com> wrote:
>>>> From: Daniel Jurgens <danielj@mellanox.com>
>>>>
>>>> Use CPUs on the close NUMA when setting the EQ affinity hints.
>>> Dan, are we sure there are no down-sides for always doing this? this
>>> code is probably there for many years and we're introducing here new
>>> behaviour to potentially to many Ms installs when they get distro
>>> update that includes this patch.
>
>> I don't see a downside, this just favors using the node local CPUs before others.
> OK, so this just favors before others and not limits (not in front of
> the code now)? would be good to improve the change log and make this
> clear.
Right, doesn't limit. Just favors the local node. I can work with Tariq to update the commit message if you think it necessary.
^ permalink raw reply
* RE: [PATCH net-next 6/9] net/mlx4_en: Adding support of turning off link autonegotiation via ethtool
From: Ariel Levkovich @ 2017-01-16 23:08 UTC (permalink / raw)
To: Or Gerlitz, Tariq Toukan
Cc: David S. Miller, Linux Netdev List, Eran Ben Elisha
In-Reply-To: <CAJ3xEMjEPQv=Agz5Wr-2UEL+iv7nz4NAcpCKY9=C4vs6SfKLLA@mail.gmail.com>
+ MLX4_PTYS_AN_DISABLE_CAP = 1 << 5,
It's there.
Best Regards,
Ariel Levkovich
Staff Engineer, SW
Mellanox Technologies
Beit Mellanox, Yokneam, P.O.Box 586, Israel 20692
Office: +972-74723-7652, Mobile: +972-52-3947-704
www.mellanox.com
Follow us on Facebook and Twitter
> -----Original Message-----
> From: Or Gerlitz [mailto:gerlitz.or@gmail.com]
> Sent: Monday, January 16, 2017 4:48 PM
> To: Tariq Toukan <tariqt@mellanox.com>; Ariel Levkovich
> <lariel@mellanox.com>
> Cc: David S. Miller <davem@davemloft.net>; Linux Netdev List
> <netdev@vger.kernel.org>; Eran Ben Elisha <eranbe@mellanox.com>
> Subject: Re: [PATCH net-next 6/9] net/mlx4_en: Adding support of turning
> off link autonegotiation via ethtool
>
> On Mon, Jan 16, 2017 at 7:30 PM, Tariq Toukan <tariqt@mellanox.com>
> wrote:
> 0644
> > --- a/include/linux/mlx4/device.h
> > +++ b/include/linux/mlx4/device.h
> > @@ -1539,8 +1539,13 @@ enum mlx4_ptys_proto {
> > MLX4_PTYS_EN = 1<<2,
> > };
> >
> > +enum mlx4_ptys_flags {
> > + MLX4_PTYS_AN_DISABLE_CAP = 1 << 5,
> > + MLX4_PTYS_AN_DISABLE_ADMIN = 1 << 6, };
> > +
> > struct mlx4_ptys_reg {
> > - u8 resrvd1;
> > + u8 flags;
> > u8 local_port;
> > u8 resrvd2;
> > u8 proto_mask;
>
> Hi Ariel,
>
> I didn't see any new dev cap bit, what happens with FW version which don't
> support this, is the result well defined? what is it?
>
> Or.
^ permalink raw reply
* [PATCH net-next] bridge: sparse fixes in br_ip6_multicast_alloc_query()
From: Lance Richardson @ 2017-01-16 23:11 UTC (permalink / raw)
To: netdev
Changed type of csum field in struct igmpv3_query from __be16 to
__sum16 to eliminate type warning, made same change in struct
igmpv3_report for consistency.
Fixed up an ntohs() where htons() should have been used instead.
Signed-off-by: Lance Richardson <lrichard@redhat.com>
---
include/uapi/linux/igmp.h | 4 ++--
net/bridge/br_multicast.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/uapi/linux/igmp.h b/include/uapi/linux/igmp.h
index ccbb32a..a97f9a7 100644
--- a/include/uapi/linux/igmp.h
+++ b/include/uapi/linux/igmp.h
@@ -53,7 +53,7 @@ struct igmpv3_grec {
struct igmpv3_report {
__u8 type;
__u8 resv1;
- __be16 csum;
+ __sum16 csum;
__be16 resv2;
__be16 ngrec;
struct igmpv3_grec grec[0];
@@ -62,7 +62,7 @@ struct igmpv3_report {
struct igmpv3_query {
__u8 type;
__u8 code;
- __be16 csum;
+ __sum16 csum;
__be32 group;
#if defined(__LITTLE_ENDIAN_BITFIELD)
__u8 qrv:3,
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index b30e77e..f6634612 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -540,7 +540,7 @@ static struct sk_buff *br_ip6_multicast_alloc_query(struct net_bridge *br,
break;
case 2:
mld2q = (struct mld2_query *)icmp6_hdr(skb);
- mld2q->mld2q_mrc = ntohs((u16)jiffies_to_msecs(interval));
+ mld2q->mld2q_mrc = htons((u16)jiffies_to_msecs(interval));
mld2q->mld2q_type = ICMPV6_MGM_QUERY;
mld2q->mld2q_code = 0;
mld2q->mld2q_cksum = 0;
--
2.5.5
^ permalink raw reply related
* Re: [pull request][for-next] Mellanox mlx5 Reorganize core driver directory layout
From: Saeed Mahameed @ 2017-01-16 23:36 UTC (permalink / raw)
To: Tom Herbert
Cc: David Miller, Saeed Mahameed, Doug Ledford, Linux Netdev List,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Leon Romanovsky
In-Reply-To: <CALx6S377hzH8_DbUSKafkbCzMEunr0H7vrfcb2WfEWFHFnfUpw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Jan 16, 2017 at 11:06 PM, Tom Herbert <tom-BjP2VixgY4xUbtYUoyoikg@public.gmane.org> wrote:
> On Mon, Jan 16, 2017 at 12:30 PM, Saeed Mahameed
> <saeedm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> wrote:
>> On Sat, Jan 14, 2017 at 12:07 AM, Saeed Mahameed
>> <saeedm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> wrote:
>>> On Fri, Jan 13, 2017 at 7:14 PM, David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
>>>> From: Saeed Mahameed <saeedm-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
>>>> Date: Thu, 12 Jan 2017 19:22:34 +0200
>>>>
>>>>> This pull request includes one patch from Leon, this patch as described
>>>>> below will change the driver directory structure and layout for better,
>>>>> logical and modular driver files separation.
>>>>>
>>>>> This change is important to both rdma and net maintainers in order to
>>>>> have smoother management of driver patches for different mlx5 sub modules
>>>>> and smoother rdma-next vs. net-next features submissions.
>>>>>
>>>>> Please find more info below -in the tag commit message-,
>>>>> review and let us know if there's any problem.
>>>>>
>>>>> This change doesn't introduce any conflicts with the current mlx5
>>>>> fixes and cleanups posted on 2017-01-10 to net branch, and merge tests
>>>>> worked flawlessly with no issues.
>>>>>
>>>>> This is the last pull request meant for both rdma-next and net-next.
>>>>> Once pulled, this will be the base shared code for both trees.
>>>>
>>>> This is pretty crazy, it will make all bug fix backporting to -stable
>>>> a complete nightmare for myself, Doug, various distribution maintainers
>>>> and many other people who quietly have to maintain their own trees and
>>>> do backporting.
>>>>
>>>
>>> I hear you,
>>> But please bear with me here, what if we queue this patch up to -stable ? and we
>>> (Mellanox) and specifically our dedicated inbox team, will make sure
>>> that this patch
>>> will land on the various distributions and for those maintaining their
>>> own trees.
>>> This patch is really straight forward (rename files) and I already
>>> tried to cherry-pick it
>>> on older kernels, I only got a couple of conflicts on some of the
>>> "#inlcude" lines we've
>>> changed, and they are pretty straightforward to fix, we can even avoid
>>> this if we decide to
>>> not move mlx5 header files in this phase.
>>>
>>> If this is possible then all trees will be aligned and it will be a
>>> win win situation.
>>>
>>
>> Hi Dave,
>>
>> Any chance you saw my -stable suggestion above ?
>> I think it would really close the backporting gap.
>>
>> Sorry i am bothering you with this topic, but we really desire the new
>> structure and
>> I never got your feedback on this suggestion, so i would like to hear
>> your thoughts.
>>
> Saeed,
>
> I've already you specific suggestions on your new structure, please
> consider your reviewers feedback more carefully. Again, the starting
I know, sorry i didn't respond on time, I though Leno's response was sufficient.
> point for your restructuring should be to separate out the minimum set
> of files required to build reasonable driver and then cleanly
> compartmentalize the rest of the features to make it easy for your
> users to include or not include those in their build. Unless you've
I see your point and i am 100% with you on this, we are all on the
same page here,
we all want to achieve the same goal -modular break down and features
logic separation-.
And in order to achieve this we need to do some big steps.
some of them will have real benefits and others are just moving code around.
One thing I need to point out (that Leon already mentioned) that the
current driver files sitting flat
in mlx5/core directory can be categorized to 4 categories
1. core related & init flows
2. common (infinband/ethernet resource management API)
3. infiniband related logic and FW commands
4. ethernet related logic and FW commands
so we figured that first we should split the bigger chunks (ethernet
vs. inifniband) into their own directories.
then i can follow up with ethernet features break down and kconfig separation.
> done this I'm not seeing much benefit for this restructuring. Also, I
> would rather see this done in one shot then expecting some sort of
> evolution over time to the right solution-- as Dave said the
> complexity of this driver is to far down the road to do that.
>
Well, I also prefer to do this in one shot, but I don't want to start
wasting time doing such a huge change
then get a NACK on submission.
Let's assume we did this in one shot i.e:
1. restructure files and directories
2. re-arrange code (separate logic)
3. Kconfig features control - to show the immediate benefit of this change
If this is acceptable by you and we get Dave's blessing on this then i
would be happy to provide (as this is our
long term plan), but if Dave doesn't approve, then ... I don't really know.
Also for 1. backporting is really easy since such patch can be applied
easily to any kernel release back to 4.4.
but 2. and 3. are really tricky ones.
> Tom
>
>> Thanks,
>> Saeed.
>>
>>>> I really don't think you can justify this rearrangement based upon the
>>>> consequences and how much activity happens in this driver.
>>>>
>>>
>>> Right, but this is not the only justification, I can sum it up to that
>>> we would like
>>> to lay out the foundation for many years to come for a well designed
>>> driver with a modular
>>> sub modules break down and scalable infrastructure. We already plan to
>>> submit more mlx5
>>> independent sub modules - just like mlx5e (en_*) files and mlx5_ib
>>> driver- so this was also
>>> a reason for us to consider this re-engagement at this stage.
>>>
>>>> You should have thought long and hard about the layout a long time ago
>>>> rather than after the driver has been in the tree for many years.
>>>>
>>>
>>> I had this Idea for the separation before the mlx5 Ethernet
>>> submission, but I wasn't the maintainer
>>> back then, and i have been itching to submit such patch for long as
>>> well, still i don't think
>>> it is too late, We (Me and Leon) will keep maintaining this driver for
>>> only god knows how many years to come,
>>> and the mlx5 drivers are meant to serve at least 3-4 more future HW generations.
>>>
>>> Long story short, We would like to re-arrange the driver in a way that
>>> would serve us (the maintainers) and serve those
>>> who are going do develop the future Stack features and the future HW
>>> generations over the well designed (Hopefully)
>>> mlx5 infrastructure.
>>> Keeping it as it is today, will only make the situation worst in the
>>> future and it will be really hard to avoid having a spaghetti code
>>> in the mlx5 driver. All i want to point out here is that maintaining
>>> such a flat subtree is also nightmare.
>>>
>>> So i am only asking you to reconsider this change and give my -stable
>>> suggestion a thought.
>>>
>>> Thank you.
>>> Saeed.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH net] vxlan: fix byte order of vxlan-gpe port number
From: Lance Richardson @ 2017-01-16 23:37 UTC (permalink / raw)
To: netdev, jbenc
vxlan->cfg.dst_port is in network byte order, so an htons()
is needed here. Also reduced comment length to stay closer
to 80 column width (still slightly over, however).
Fixes: e1e5314de08b ("vxlan: implement GPE")
Signed-off-by: Lance Richardson <lrichard@redhat.com>
---
drivers/net/vxlan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index ca7196c..8a79cfc 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -2890,7 +2890,7 @@ static int vxlan_dev_configure(struct net *src_net, struct net_device *dev,
memcpy(&vxlan->cfg, conf, sizeof(*conf));
if (!vxlan->cfg.dst_port) {
if (conf->flags & VXLAN_F_GPE)
- vxlan->cfg.dst_port = 4790; /* IANA assigned VXLAN-GPE port */
+ vxlan->cfg.dst_port = htons(4790); /* IANA VXLAN-GPE port */
else
vxlan->cfg.dst_port = default_port;
}
--
2.5.5
^ permalink raw reply related
* [PATCH 1/1] ip: fix igmp parsing when iface is long
From: Petr Vorel @ 2017-01-16 23:25 UTC (permalink / raw)
To: netdev; +Cc: Petr Vorel
Entries with long vhost names in /proc/net/igmp have no whitespace
between name and colon, so sscanf() adds it to vhost and
'ip maddr show iface' doesn't include inet result.
Signed-off-by: Petr Vorel <pvorel@suse.cz>
---
ip/ipmaddr.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/ip/ipmaddr.c b/ip/ipmaddr.c
index 22eb407..4f726fd 100644
--- a/ip/ipmaddr.c
+++ b/ip/ipmaddr.c
@@ -136,13 +136,17 @@ static void read_igmp(struct ma_info **result_p)
while (fgets(buf, sizeof(buf), fp)) {
struct ma_info *ma;
+ size_t len;
if (buf[0] != '\t') {
sscanf(buf, "%d%s", &m.index, m.name);
+ len = strlen(m.name);
+ if (m.name[len - 1] == ':')
+ len--;
continue;
}
- if (filter.dev && strcmp(filter.dev, m.name))
+ if (filter.dev && strncmp(filter.dev, m.name, len))
continue;
sscanf(buf, "%08x%d", (__u32 *)&m.addr.data, &m.users);
--
2.11.0
^ 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