From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 48528C433ED for ; Thu, 22 Apr 2021 23:28:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 07EBB61425 for ; Thu, 22 Apr 2021 23:28:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239691AbhDVX3C (ORCPT ); Thu, 22 Apr 2021 19:29:02 -0400 Received: from m43-7.mailgun.net ([69.72.43.7]:59612 "EHLO m43-7.mailgun.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235977AbhDVX3C (ORCPT ); Thu, 22 Apr 2021 19:29:02 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1619134107; h=Message-ID: References: In-Reply-To: Subject: Cc: To: From: Date: Content-Transfer-Encoding: Content-Type: MIME-Version: Sender; bh=5otw7omBiCFqynsjT0aagj3xpb8pMiXtl1joNgN82cI=; b=i1+Sj53uw5N8rfeDUfxC3wteQLsJUWhm+HVOEuQtjXKWBFWvGeBCZ5r4n1ddocnj0gO1Ea/x xKnlsPJlTlzYznPohyKLi32RebcoEHGoSPYbGlmmPJMDluIKPGm4nyGJDKdXBqjc4ssftDQ4 h73/SOfODezR2KEwZ6Po3ytoT0g= X-Mailgun-Sending-Ip: 69.72.43.7 X-Mailgun-Sid: WyJiZjI2MiIsICJuZXRkZXZAdmdlci5rZXJuZWwub3JnIiwgImJlOWU0YSJd Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by smtp-out-n06.prod.us-east-1.postgun.com with SMTP id 608206872cbba88980825f3f (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Thu, 22 Apr 2021 23:28:07 GMT Sender: subashab=codeaurora.org@mg.codeaurora.org Received: by smtp.codeaurora.org (Postfix, from userid 1001) id 3B54DC43217; Thu, 22 Apr 2021 23:28:07 +0000 (UTC) Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: subashab) by smtp.codeaurora.org (Postfix) with ESMTPSA id 769B3C433F1; Thu, 22 Apr 2021 23:28:06 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 22 Apr 2021 17:28:06 -0600 From: subashab@codeaurora.org To: Alex Elder Cc: Bjorn Andersson , Sean Tranchetti , "David S. Miller" , Jakub Kicinski , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Daniele Palmas , Aleksander Morgado , Loic Poulain Subject: Re: [PATCH] net: qualcomm: rmnet: Allow partial updates of IFLA_FLAGS In-Reply-To: <76db0c51-15be-2d27-00a7-c9f8dc234816@linaro.org> References: <20210422182045.1040966-1-bjorn.andersson@linaro.org> <76db0c51-15be-2d27-00a7-c9f8dc234816@linaro.org> Message-ID: <89526b9845cc86143da2221fc2445557@codeaurora.org> X-Sender: subashab@codeaurora.org User-Agent: Roundcube Webmail/1.3.9 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 2021-04-22 12:29, Alex Elder wrote: > On 4/22/21 1:20 PM, Bjorn Andersson wrote: >> The idiomatic way to handle the changelink flags/mask pair seems to be >> allow partial updates of the driver's link flags. In contrast the >> rmnet >> driver masks the incoming flags and then use that as the new flags. >> >> Change the rmnet driver to follow the common scheme, before the >> introduction of IFLA_RMNET_FLAGS handling in iproute2 et al. > > I like this a lot. It should have been implemented this way > to begin with; there's not much point to have the mask if > it's only applied to the passed-in value. > > KS, are you aware of *any* existing user space code that > would not work correctly if this were accepted? > > I.e., the way it was (is), the value passed in *assigns* > the data format flags. But with Bjorn's changes, the > data format flags would be *updated* (i.e., any bits not > set in the mask field would remain with their previous > value). > > Reviewed-by: Alex Elder What rmnet functionality which was broken without this change. That doesnt seem to be listed in this patch commit text. If this is an enhancement, then patch needs to be targeted to net-next instead of net