> Hi, Yuval
>
> On 2017/10/15 13:14, Yuval Mintz wrote:
> >> Hi, Yuval
> >>
> >> On 2017/10/13 4:21, Yuval Mintz wrote:
> >>>> This patchset adds a new hardware offload type in mqprio before
> adding
> >>>> mqprio hardware o
> Hi, Yuval
>
> On 2017/10/15 13:14, Yuval Mintz wrote:
> >> Hi, Yuval
> >>
> >> On 2017/10/13 4:21, Yuval Mintz wrote:
> >>>> This patchset adds a new hardware offload type in mqprio before
> adding
> >>>> mqprio hardware o
> > >> This patchset adds a new hardware offload type in mqprio before
> adding
> > >> mqprio hardware offload support in hns3 driver.
Apparently Dave has already acceptedAmirtha's changes to mqprio:
https://marc.info/?l=linux-netdev=150803219824053=2
so I guess you need to revise your
> > >> This patchset adds a new hardware offload type in mqprio before
> adding
> > >> mqprio hardware offload support in hns3 driver.
Apparently Dave has already acceptedAmirtha's changes to mqprio:
https://marc.info/?l=linux-netdev=150803219824053=2
so I guess you need to revise your
> Hi, Yuval
>
> On 2017/10/13 4:21, Yuval Mintz wrote:
> >> This patchset adds a new hardware offload type in mqprio before adding
> >> mqprio hardware offload support in hns3 driver.
> >
> > I think one of the biggest issues in tying this to DCB
> Hi, Yuval
>
> On 2017/10/13 4:21, Yuval Mintz wrote:
> >> This patchset adds a new hardware offload type in mqprio before adding
> >> mqprio hardware offload support in hns3 driver.
> >
> > I think one of the biggest issues in tying this to DCB
> This patchset adds a new hardware offload type in mqprio before adding
> mqprio hardware offload support in hns3 driver.
I think one of the biggest issues in tying this to DCB configuration is the
non-immediate [and possibly non persistent] configuration.
Scenario #1:
User is configuring
> This patchset adds a new hardware offload type in mqprio before adding
> mqprio hardware offload support in hns3 driver.
I think one of the biggest issues in tying this to DCB configuration is the
non-immediate [and possibly non persistent] configuration.
Scenario #1:
User is configuring
> When a driver supports both dcb and hardware offloaded mqprio, and
> user is running mqprio and dcb tool concurrently, the configuration
> set by each tool may be conflicted with each other because the dcb
(for second 'each') s/each/the
> and mqprio may be using the same hardwere offload
> When a driver supports both dcb and hardware offloaded mqprio, and
> user is running mqprio and dcb tool concurrently, the configuration
> set by each tool may be conflicted with each other because the dcb
(for second 'each') s/each/the
> and mqprio may be using the same hardwere offload
> Hi, Yuval
>
> On 2017/9/26 14:43, Yuval Mintz wrote:
> >> When using tc qdisc to configure DCB parameter, dcb_ops->setup_tc
> >> is used to tell hclge_dcb module to do the setup.
> >
> > While this might be a step in the right direction, this causes an
> Hi, Yuval
>
> On 2017/9/26 14:43, Yuval Mintz wrote:
> >> When using tc qdisc to configure DCB parameter, dcb_ops->setup_tc
> >> is used to tell hclge_dcb module to do the setup.
> >
> > While this might be a step in the right direction, this causes an
> When using tc qdisc to configure DCB parameter, dcb_ops->setup_tc
> is used to tell hclge_dcb module to do the setup.
While this might be a step in the right direction, this causes an inconsistency
in user experience - Some [well, most] vendors didn't allow the mqprio
priority mapping to affect
> When using tc qdisc to configure DCB parameter, dcb_ops->setup_tc
> is used to tell hclge_dcb module to do the setup.
While this might be a step in the right direction, this causes an inconsistency
in user experience - Some [well, most] vendors didn't allow the mqprio
priority mapping to affect
>
>
> In fact, these functions are only used in the file in which they are
> declared and don't need a declaration, but can be made static.
> so this patch marks these functions with 'static'.
...
> -void qed_get_vport_stats(struct qed_dev *cdev,
> - struct qed_eth_stats
>
>
> In fact, these functions are only used in the file in which they are
> declared and don't need a declaration, but can be made static.
> so this patch marks these functions with 'static'.
...
> -void qed_get_vport_stats(struct qed_dev *cdev,
> - struct qed_eth_stats
ed
> a declaration, but can be made static.
> so this patch marks this function with 'static'.
>
> Signed-off-by: Baoyou Xie <baoyou....@linaro.org>
Thanks.
Acked-by: Yuval Mintz <yuval.mi...@qlogic.com>
ed
> a declaration, but can be made static.
> so this patch marks this function with 'static'.
>
> Signed-off-by: Baoyou Xie
Thanks.
Acked-by: Yuval Mintz
orruption on some configurations but maybe not on others.
O.k., motivation is clear.
But this really isn't enforced by the ansi-c standard, right?
Anyway, thanks.
Acked-by: Yuval Mintz <yuval.mi...@qlogic.com>
orruption on some configurations but maybe not on others.
O.k., motivation is clear.
But this really isn't enforced by the ansi-c standard, right?
Anyway, thanks.
Acked-by: Yuval Mintz
> We get a few warnings when building kernel with W=1:
> drivers/net/ethernet/qlogic/qed/qed_l2.c:112:5: warning: no previous
> prototype for 'qed_sp_vport_start' [-Wmissing-prototypes]
>
>
> In fact, these functions are only used in the file in which they are
> declared and don't need a
> We get a few warnings when building kernel with W=1:
> drivers/net/ethernet/qlogic/qed/qed_l2.c:112:5: warning: no previous
> prototype for 'qed_sp_vport_start' [-Wmissing-prototypes]
>
>
> In fact, these functions are only used in the file in which they are
> declared and don't need a
> We get 4 warnings when building kernel with W=1:
> drivers/net/ethernet/qlogic/qed/qed_selftest.c:6:5: warning: no previous
> prototype for 'qed_selftest_memory' [-Wmissing-prototypes]
> drivers/net/ethernet/qlogic/qed/qed_selftest.c:19:5: warning: no previous
> prototype for
> We get 4 warnings when building kernel with W=1:
> drivers/net/ethernet/qlogic/qed/qed_selftest.c:6:5: warning: no previous
> prototype for 'qed_selftest_memory' [-Wmissing-prototypes]
> drivers/net/ethernet/qlogic/qed/qed_selftest.c:19:5: warning: no previous
> prototype for
possible.
>
> Signed-off-by: Joe Perches <j...@perches.com>
Looking good. Thanks Joe.
Acked-by: Yuval Mintz <yuval.mi...@qlogic.com>
le.
>
> Signed-off-by: Joe Perches
Looking good. Thanks Joe.
Acked-by: Yuval Mintz
n' in title
[net/net-next]? Or is it good as-is?
In case of latter,
Acked-by: Yuval Mintz <yuval.mi...@qlogic.com>
One question the automated script -
Can't it [relative] easily be upgraded to also have 'Fixes:' as part of its
message?
inelle/api/alloc/kzalloc-simple.cocci
>
> CC: Sudarsana Reddy Kalluru
> Signed-off-by: Fengguang Wu
This looks fine; But what's the right process here -
Dave - do we need to re-post this with the the right 'destination' in title
[net/net-next]? Or is it good as-is?
In case of latt
> Currently the tx channels share same pool of descriptors. Thus one channel can
> block another if pool is emptied by one. But, the shaper should decide which
> channel is allowed to send packets. To avoid such impact of one channel on
> another, let every channel to have its own peace of pool.
> Currently the tx channels share same pool of descriptors. Thus one channel can
> block another if pool is emptied by one. But, the shaper should decide which
> channel is allowed to send packets. To avoid such impact of one channel on
> another, let every channel to have its own peace of pool.
> 81xx has only 4 CPUs, so it doesn't make sense to initialize entire Qset i.e 8
> queues by default. Made changes to queue initialization to init queues equal
> to
> number of CPUs or
> 8 queues whichever is lesser. Also this will be applicable to VMs with VNIC VF
> attached and having less
> 81xx has only 4 CPUs, so it doesn't make sense to initialize entire Qset i.e 8
> queues by default. Made changes to queue initialization to init queues equal
> to
> number of CPUs or
> 8 queues whichever is lesser. Also this will be applicable to VMs with VNIC VF
> attached and having less
> +static void netvsc_inject_enable(struct net_device_context
> +*net_device_ctx) {
> + net_device_ctx->vf_inject = true;
> +}
> +
> +static void netvsc_inject_disable(struct net_device_context
> +*net_device_ctx) {
> + net_device_ctx->vf_inject = false;
> +
> + /* Wait for currently
> +static void netvsc_inject_enable(struct net_device_context
> +*net_device_ctx) {
> + net_device_ctx->vf_inject = true;
> +}
> +
> +static void netvsc_inject_disable(struct net_device_context
> +*net_device_ctx) {
> + net_device_ctx->vf_inject = false;
> +
> + /* Wait for currently
> Do not write random bytes from the kernel stack when calling qed_wr.
>
> Signed-off-by: Heinrich Schuchardt <xypron.g...@gmx.de>
Thanks.
Acked-by: Yuval Mintz <yuval.mi...@qlogic.com>
> Do not write random bytes from the kernel stack when calling qed_wr.
>
> Signed-off-by: Heinrich Schuchardt
Thanks.
Acked-by: Yuval Mintz
> > Current DP_ macros generate a lot of code.
> > Using functions with vsprintf extension %pV helps reduce that size.
>
> Yuval, I used the same KERN_ output types, but it is unusual
> that DP_INFO outputs at KERN_NOTICE.
>
> Was that a copy/paste defect or should it be emitted at KERN_INFO and
> > Current DP_ macros generate a lot of code.
> > Using functions with vsprintf extension %pV helps reduce that size.
>
> Yuval, I used the same KERN_ output types, but it is unusual
> that DP_INFO outputs at KERN_NOTICE.
>
> Was that a copy/paste defect or should it be emitted at KERN_INFO and
> Current DP_ macros generate a lot of code.
> Using functions with vsprintf extension %pV helps reduce that size.
>
> drivers/net/ethernet/qlogic/qed/Makefile | 2 +-
> drivers/net/ethernet/qlogic/qed/qed_util.c | 82
> ++
> include/linux/qed/qed_if.h
> Current DP_ macros generate a lot of code.
> Using functions with vsprintf extension %pV helps reduce that size.
>
> drivers/net/ethernet/qlogic/qed/Makefile | 2 +-
> drivers/net/ethernet/qlogic/qed/qed_util.c | 82
> ++
> include/linux/qed/qed_if.h
;
> As discussed, we also use a compile-time check to ensure we never use any of
> the VF code if CONFIG_QED_SRIOV is disabled, and the PCI device table is
> updated to no longer bind to virtual functions in that configuration.
>
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
;
> As discussed, we also use a compile-time check to ensure we never use any of
> the VF code if CONFIG_QED_SRIOV is disabled, and the PCI device table is
> updated to no longer bind to virtual functions in that configuration.
>
> Signed-off-by: Arnd Bergmann
>
> ---
> On Wednes
> > > I think we can just remove the IS_ENABLED() check there and define
> > > the
> > > IS_PF() macro conditionally to become 'true' if CONFIG_QED_SRIOV is
> > > not set, like some other drivers do
> >
> > I think that would be unsafe with current qede - qede currently
> > publishes its VFs' PCI
> > > I think we can just remove the IS_ENABLED() check there and define
> > > the
> > > IS_PF() macro conditionally to become 'true' if CONFIG_QED_SRIOV is
> > > not set, like some other drivers do
> >
> > I think that would be unsafe with current qede - qede currently
> > publishes its VFs' PCI
> > I think both solutions are equally valid/elegant.
> >
> > Arnd?
>
> I think we can just remove the IS_ENABLED() check there and define the
> IS_PF() macro conditionally to become 'true' if CONFIG_QED_SRIOV is not set,
> like some other drivers do
>
> diff --git
> > I think both solutions are equally valid/elegant.
> >
> > Arnd?
>
> I think we can just remove the IS_ENABLED() check there and define the
> IS_PF() macro conditionally to become 'true' if CONFIG_QED_SRIOV is not set,
> like some other drivers do
>
> diff --git
vfpf_acquire().
>
> Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com>
Thanks.
Acked-by: Yuval Mintz <yuval.mi...@qlogic.com>
vfpf_acquire().
>
> Signed-off-by: Vitaly Kuznetsov
Thanks.
Acked-by: Yuval Mintz
> + if (IS_ENABLED(CONFIG_QED_SRIOV) && !IS_PF(hwfn->cdev)) {
> + qed_vf_get_link_params(hwfn, params);
> + qed_vf_get_link_state(hwfn, link);
> + qed_vf_get_link_caps(hwfn, link_caps);
> +
> + return 0;
> + }
The IS_ENABLED here seems a bit
> + if (IS_ENABLED(CONFIG_QED_SRIOV) && !IS_PF(hwfn->cdev)) {
> + qed_vf_get_link_params(hwfn, params);
> + qed_vf_get_link_state(hwfn, link);
> + qed_vf_get_link_caps(hwfn, link_caps);
> +
> + return 0;
> + }
The IS_ENABLED here seems a bit
> Hello there,
>
> drivers/net/ethernet/qlogic/qed/qed_dcbx.c:210:16: warning: comparison is
> always false due to limited range of data type [-Wtype-limits]
>
> Source code is
>
>if (priority < 0) {
>
> but
>
> u8 tc, priority, priority_map;
>
>
> Regards
>
> David Binderman
> Hello there,
>
> drivers/net/ethernet/qlogic/qed/qed_dcbx.c:210:16: warning: comparison is
> always false due to limited range of data type [-Wtype-limits]
>
> Source code is
>
>if (priority < 0) {
>
> but
>
> u8 tc, priority, priority_map;
>
>
> Regards
>
> David Binderman
> Upgrading a system from kernel 4.2 to 4.6rc7, there is an extra 2 minute delay
> while booting due to these problems:
>
> [ 47.977221] bnx2x :04:00.1: Direct firmware load for
> bnx2x/bnx2x-e2-
> 7.13.1.0.fw failed with error -2
...
> Could the driver fall back to an older firmware
> Upgrading a system from kernel 4.2 to 4.6rc7, there is an extra 2 minute delay
> while booting due to these problems:
>
> [ 47.977221] bnx2x :04:00.1: Direct firmware load for
> bnx2x/bnx2x-e2-
> 7.13.1.0.fw failed with error -2
...
> Could the driver fall back to an older firmware
colin.k...@canonical.com>
Thanks Colin.
Acked-by: Yuval Mintz <yuval.mi...@qlogic.com>
> From: Colin Ian King
>
> in the case where qed_slowpath_irq_req is not called, rc is not assigned and
> so
> qed_int_igu_enable will return a garbage value.
> Fix this by initializing rc to 0.
>
> Signed-off-by: Colin Ian King
Thanks Colin.
Acked-by: Yuval Mintz
(CONFIG_BNX2X_GENEVE)' [It not a tristate].
But that's truly insignificant.
Acked-By: Yuval Mintz <yuval.mi...@qlogic.com>
X_GENEVE)' [It not a tristate].
But that's truly insignificant.
Acked-By: Yuval Mintz
> > After merging the net-next tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > In file included from drivers/net/ethernet/broadcom/bnx2x/bnx2x.h:56:0,
> > from drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c:30:
> >
> > After merging the net-next tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > In file included from drivers/net/ethernet/broadcom/bnx2x/bnx2x.h:56:0,
> > from drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c:30:
> >
> > Isn't AE_VERSION_1 something fixed once you publish your features?
> > If it can't be changed, why not simply remove the features from
> > `hw_features' instead of having to implement this ndo?
> There could be a case where the feature is supported by the SoC
> and therefore it is already part
> > Isn't AE_VERSION_1 something fixed once you publish your features?
> > If it can't be changed, why not simply remove the features from
> > `hw_features' instead of having to implement this ndo?
> There could be a case where the feature is supported by the SoC
> and therefore it is already part
> +static netdev_features_t hns_nic_fix_features(
> + struct net_device *netdev, netdev_features_t features) {
> + struct hns_nic_priv *priv = netdev_priv(netdev);
> +
> + switch (priv->enet_ver) {
> + case AE_VERSION_1:
> + features &= ~(NETIF_F_TSO |
> static void hns_ppe_init_hw(struct hns_ppe_cb *ppe_cb) {
...
> + /* Set default RSS key and indrection table*/
> + const u32 rss_key[HNS_PPEV2_RSS_KEY_NUM] = {
> + 0x6d5a56da, 0x255b0ec2,
> + 0x4167253d, 0x43a38fb0,
> + 0xd0ca2bcb, 0xae7b30b4,
> +
> +void hns_rcbv2_int_ctrl_hw(struct hnae_queue *q, u32 flag, u32 mask)
> +{
> + u32 int_mask_en = !!mask;
> +
> + if (flag & RCB_INT_FLAG_TX)
> + dsaf_write_dev(q, RCB_RING_INTMSK_TXWL_REG,
> int_mask_en);
> +
> + if (flag & RCB_INT_FLAG_RX)
> +
> +static void hns_ae_set_tso_stats(struct hnae_handle *handle, int
> +enable) {
> + struct hns_ppe_cb *ppe_cb = hns_get_ppe_cb(handle);
> +
> + hns_ppe_set_tso_enable(ppe_cb, enable); }
Style issues?
> +void hns_ppe_set_tso_enable(struct hns_ppe_cb *ppe_cb, u32 value) {
> +
> +static void hns_ae_set_tso_stats(struct hnae_handle *handle, int
> +enable) {
> + struct hns_ppe_cb *ppe_cb = hns_get_ppe_cb(handle);
> +
> + hns_ppe_set_tso_enable(ppe_cb, enable); }
Style issues?
> +void hns_ppe_set_tso_enable(struct hns_ppe_cb *ppe_cb, u32 value) {
> +
> +static netdev_features_t hns_nic_fix_features(
> + struct net_device *netdev, netdev_features_t features) {
> + struct hns_nic_priv *priv = netdev_priv(netdev);
> +
> + switch (priv->enet_ver) {
> + case AE_VERSION_1:
> + features &= ~(NETIF_F_TSO |
> +void hns_rcbv2_int_ctrl_hw(struct hnae_queue *q, u32 flag, u32 mask)
> +{
> + u32 int_mask_en = !!mask;
> +
> + if (flag & RCB_INT_FLAG_TX)
> + dsaf_write_dev(q, RCB_RING_INTMSK_TXWL_REG,
> int_mask_en);
> +
> + if (flag & RCB_INT_FLAG_RX)
> +
> static void hns_ppe_init_hw(struct hns_ppe_cb *ppe_cb) {
...
> + /* Set default RSS key and indrection table*/
> + const u32 rss_key[HNS_PPEV2_RSS_KEY_NUM] = {
> + 0x6d5a56da, 0x255b0ec2,
> + 0x4167253d, 0x43a38fb0,
> + 0xd0ca2bcb, 0xae7b30b4,
> +
> I assume that it is not possible to change the ABI any more, otherwise
> we should try to use a 64-bit field.
Actually, I did suggest exactly that to our management team,
But this was the decided ABI.
Acked-by: Yuval Mintz
--
To unsubscribe from this list: send the line "unsubs
> I assume that it is not possible to change the ABI any more, otherwise
> we should try to use a 64-bit field.
Actually, I did suggest exactly that to our management team,
But this was the decided ABI.
Acked-by: Yuval Mintz <yuval.mi...@qlogic.com>
--
To unsubscribe from thi
> I am used to sending out one patch per each fix like this for each function.
> If you don't like me doing this I don't when sending patches for your
> subsystem(s).
I think that would be preferable.
> In addition would something like this fix your complains about not fixing
> error
> handling
> This fixes the error handling in the function bnxc2x_dbcx_params for both
> calls
> to bnx2x_dcbnl_update_applist by checking if they failed by returning a error
> code and if so return immediately to this function's caller due to this
> nonrecoverable internal failure.
Hi Nicholas,
Even
This fixes the error handling in the function bnxc2x_dbcx_params for both
calls
to bnx2x_dcbnl_update_applist by checking if they failed by returning a error
code and if so return immediately to this function's caller due to this
nonrecoverable internal failure.
Hi Nicholas,
Even assuming
I am used to sending out one patch per each fix like this for each function.
If you don't like me doing this I don't when sending patches for your
subsystem(s).
I think that would be preferable.
In addition would something like this fix your complains about not fixing
error
handling in
> > I'have installed a new DELL VRTX M620 Blade with kernel 3.18.11.
> > After system startup I tried to activate the kernel netconsole with remote
> logging enabled.
> >
> > I executed the following command and the shell I issued it becomes
> unresponsive and hangs.
> >
> > # modprobe netconsole
I'have installed a new DELL VRTX M620 Blade with kernel 3.18.11.
After system startup I tried to activate the kernel netconsole with remote
logging enabled.
I executed the following command and the shell I issued it becomes
unresponsive and hangs.
# modprobe netconsole
> > Building with the attached random configuration file,
> >
> > drivers/built-in.o: In function `__bnx2x_remove':
> > /home/jim/linux/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:13409:
> > undefined reference to `ptp_clock_unregister'
> > drivers/built-in.o: In function
Building with the attached random configuration file,
drivers/built-in.o: In function `__bnx2x_remove':
/home/jim/linux/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:13409:
undefined reference to `ptp_clock_unregister'
drivers/built-in.o: In function `bnx2x_register_phc':
> On Mon, Jul 28, 2014 at 06:52:48PM +0200, Luis R. Rodriguez wrote:
> > On Mon, Jul 28, 2014 at 03:46:32PM +0000, Yuval Mintz wrote:
> > > Sorry for not being clear, but I didn't meant 'what guarantees that the
> > > device
> > > will be added to the deferre
> Subject: Re: [PATCH 1/3] driver core: enable drivers to use deferred probe
> from
> init
>
> On Mon, Jul 28, 2014 at 03:12:11PM +0000, Yuval Mintz wrote:
> > Perhaps this is a silly question, but what guarantees that the
> > deferred probe list will actually
> +static int __driver_probe_device(struct device_driver *drv, struct
> +device *dev) {
> + if (drv->delay_probe && !dev->init_delayed_probe) {
> + dev_info(dev, "Driver %s requests probe deferral on init\n",
> + drv->name);
> +
+static int __driver_probe_device(struct device_driver *drv, struct
+device *dev) {
+ if (drv-delay_probe !dev-init_delayed_probe) {
+ dev_info(dev, Driver %s requests probe deferral on init\n,
+ drv-name);
+ dev-init_delayed_probe = true;
+
Subject: Re: [PATCH 1/3] driver core: enable drivers to use deferred probe
from
init
On Mon, Jul 28, 2014 at 03:12:11PM +, Yuval Mintz wrote:
Perhaps this is a silly question, but what guarantees that the
deferred probe list will actually be triggered, e.g., in case the
delayed
On Mon, Jul 28, 2014 at 06:52:48PM +0200, Luis R. Rodriguez wrote:
On Mon, Jul 28, 2014 at 03:46:32PM +, Yuval Mintz wrote:
Sorry for not being clear, but I didn't meant 'what guarantees that the
device
will be added to the deferred probe', but rather what guarantees
> Also, Convert kzalloc to devm_kzalloc.
Looks like you should remove this part of the comment.
>
> Signed-off-by: George Cherian
> Reviewed-by: Felipe Balbi
> ---
> drivers/net/ethernet/ti/davinci_mdio.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
Also, Convert kzalloc to devm_kzalloc.
Looks like you should remove this part of the comment.
Signed-off-by: George Cherian george.cher...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/net/ethernet/ti/davinci_mdio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
> > > Hi Ariel.
> > >
> > > I wrote a little checkpatch script to look for missing
> > > switch/case breaks.
> > >
> > > http://www.kernelhub.org/?msg=379933=2
> > >
> > > There are _many_ instances of case blocks in sriov.c
> > > that could be missing breaks as they use fall-throughs.
> > >
> > >
Hi Ariel.
I wrote a little checkpatch script to look for missing
switch/case breaks.
http://www.kernelhub.org/?msg=379933p=2
There are _many_ instances of case blocks in sriov.c
that could be missing breaks as they use fall-throughs.
It would be good if these are
> Hi Ariel.
>
> I wrote a little checkpatch script to look for missing
> switch/case breaks.
>
> http://www.kernelhub.org/?msg=379933=2
>
> There are _many_ instances of case blocks in sriov.c
> that could be missing breaks as they use fall-throughs.
>
> It would be good if these are actually
Hi Ariel.
I wrote a little checkpatch script to look for missing
switch/case breaks.
http://www.kernelhub.org/?msg=379933p=2
There are _many_ instances of case blocks in sriov.c
that could be missing breaks as they use fall-throughs.
It would be good if these are actually intended
> Tested:
> ethtool -e eth0 raw on >first.nvram
> ethtool -E eth0 ethtool -e eth0 raw on >second.nvram
> cmp first.nvram second.nvram || ethtool -E eth0 (No output means pass.)
Hi Nate,
We're aware of this `bug' for some time - we've encountered it when
trying to fix the
Tested:
ethtool -e eth0 raw on first.nvram
ethtool -E eth0 first.nvram
ethtool -e eth0 raw on second.nvram
cmp first.nvram second.nvram || ethtool -E eth0 second.nvram
(No output means pass.)
Hi Nate,
We're aware of this `bug' for some time - we've encountered it when
Greenstein
> Cc: net...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
[...]
Acked-by: Yuval Mintz
Thanks,
Yuval
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.ke
...@broadcom.com
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
[...]
Acked-by: Yuval Mintz yuval...@broadcom.com
Thanks,
Yuval
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
nctionality from the `net-next' patch
which was lost due to the merge.
Is `linux-next' the correct tree to send it into?
(I couldn't designate it to `net-next' as the merge between `net' and
`net-next' hasn't occured yet, thus no collision there)
Signed-off-by: Yuval Mintz
Signed-off-by: Ariel Elior
-
-next' the correct tree to send it into?
(I couldn't designate it to `net-next' as the merge between `net' and
`net-next' hasn't occured yet, thus no collision there)
Signed-off-by: Yuval Mintz yuval...@broadcom.com
Signed-off-by: Ariel Elior ari...@broadcom.com
---
drivers/net/ethernet/broadcom
ress
> Capability accessors") from the pci tree.
>
> The former removes the function updated by the latter, so I just removed
> the function (see below) and can carry the fix as necessary.
Acked-by: Yuval Mintz
--
To unsubscribe from this list: send the line "unsubscribe
tree.
The former removes the function updated by the latter, so I just removed
the function (see below) and can carry the fix as necessary.
Acked-by: Yuval Mintz yuval...@broadcom.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
1 - 100 of 102 matches
Mail list logo
