From: subashab@codeaurora.org
To: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Alex Elder <elder@linaro.org>,
Sean Tranchetti <stranche@codeaurora.org>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Daniele Palmas <dnlplm@gmail.com>,
Aleksander Morgado <aleksander@aleksander.es>,
Loic Poulain <loic.poulain@linaro.org>
Subject: Re: [PATCH] net: qualcomm: rmnet: Allow partial updates of IFLA_FLAGS
Date: Thu, 22 Apr 2021 22:04:13 -0600 [thread overview]
Message-ID: <7291b240853fbf1fc6dbdc30fe4f6743@codeaurora.org> (raw)
In-Reply-To: <20210423023026.GD1908499@yoga>
> I recently posted a patch to iproute2 extending the rmnet link handling
> to handle IFLA_RMNET_FLAGS, in the discussion that followed this
> subject
> came up. So nothing is broken, it's just that the current logic doesn't
> make sense and I wanted to attempt to fix it before we start to use it
> commonly distributed userspace software (iproute2, libqmi etc)
With this patch, passing IFLA_RMNET_FLAGS in newlink vs changelink will
have
different behavior. Is that inline with your expectations.
I checked VLAN and it seems to be using the same behavior for both the
operations.
While the patch itself is fine, I don't think its right to have
different
behavior for the operations.
> Okay, please let me know what hoops you want me to jump through. I just
> want the subject concluded so that I can respin my iproute2 patch
> according to what we decide here.
My suggestion is to have the subject prefix as [PATCH net-next] since
this
is an enhancement rather than fixing something which is broken.
prev parent reply other threads:[~2021-04-23 4:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-22 18:20 [PATCH] net: qualcomm: rmnet: Allow partial updates of IFLA_FLAGS Bjorn Andersson
2021-04-22 18:29 ` Alex Elder
2021-04-22 23:28 ` subashab
2021-04-23 1:01 ` Alex Elder
2021-04-23 2:30 ` Bjorn Andersson
2021-04-23 4:04 ` subashab [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7291b240853fbf1fc6dbdc30fe4f6743@codeaurora.org \
--to=subashab@codeaurora.org \
--cc=aleksander@aleksander.es \
--cc=bjorn.andersson@linaro.org \
--cc=davem@davemloft.net \
--cc=dnlplm@gmail.com \
--cc=elder@linaro.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=loic.poulain@linaro.org \
--cc=netdev@vger.kernel.org \
--cc=stranche@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.