Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36;
Message-ID: <6456509b-9df7-47e3-b941-c307594a80d2@intel.com>
Date:   Fri, 27 Oct 2023 09:55:04 -0700
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH net-next v2 5/5] net: bcmgenet: Interrogate PHY for
 WAKE_FILTER programming
Content-Language: en-US
To:     Florian Fainelli <florian.fainelli@broadcom.com>,
        <netdev@vger.kernel.org>
CC:     Doug Berger <opendmb@gmail.com>,
        Broadcom internal kernel review list 
        <bcm-kernel-feedback-list@broadcom.com>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>, Andrew Lunn <andrew@lunn.ch>,
        Heiner Kallweit <hkallweit1@gmail.com>,
        Russell King <linux@armlinux.org.uk>,
        Vladimir Oltean <vladimir.oltean@nxp.com>,
        "Tariq Toukan" <tariqt@nvidia.com>, Gal Pressman <gal@nvidia.com>,
        Willem de Bruijn <willemb@google.com>,
        Daniil Tatianin <d-tatianin@yandex-team.ru>,
        "Simon Horman" <horms@kernel.org>,
        Justin Chen <justin.chen@broadcom.com>,
        "Ratheesh Kannoth" <rkannoth@marvell.com>,
        Joe Damato <jdamato@fastly.com>,
        "Vincent Mailhol" <mailhol.vincent@wanadoo.fr>,
        Jiri Pirko <jiri@resnulli.us>,
        "open list" <linux-kernel@vger.kernel.org>
References: <20231026224509.112353-1-florian.fainelli@broadcom.com>
 <20231026224509.112353-6-florian.fainelli@broadcom.com>
 <0a164b9b-4f9b-4886-b19e-48298cdcff8d@intel.com>
 <2eeb8e24-4122-450b-adf5-8c8a746db518@broadcom.com>
From:   Jacob Keller <jacob.e.keller@intel.com>
In-Reply-To: <2eeb8e24-4122-450b-adf5-8c8a746db518@broadcom.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WEFDbU5qbGZmZk9hS09iN2t4cGlyZjE5VU9WVUFoKy8za2hPMlJLaVVPVUc3?=
 =?utf-8?B?b0lDU1ZJeWRoUVZXRnJpZ1JYaTY5QW5HRnh6dkRVT3pGT1BacmxhTDQzZUV4?=
 =?utf-8?B?NmtCMTM5MjRTbkxvRGNTOGpvTWdYcVZnajM1NUE5ekwyZVhXcVJhZVk3V2Ri?=
 =?utf-8?B?eHFVVEN3OEs5blpzY0pKMEdIL0JOSUpTN0tUL1Z2MGx5aEdIcENOVUM1Y2J0?=
 =?utf-8?B?cy96UnNKTWNEckZPbWkwcTc1MnpsWEF4cU9nRjRSTXBGSk9CL2NFS2JLVWhw?=
 =?utf-8?B?RmoxQXFoTjFBZlNlamE4TXY2YTVRL2EzZ0Rid2laNVozcVpsK0hhZm5TNG9R?=
 =?utf-8?B?YnBRNTdkcHFLVkpCb2JBWXM5YU9EaXZ0R0dhNTIrcENjeWpWREh0cEJBV3pU?=
 =?utf-8?B?eWpSOXhoRzFBMzB0VGdxQ0hyODR0UDNMS0M5Zk9acHVUMk91Z1BYRFdPSWJ4?=
 =?utf-8?B?VVRBMithSEJsVGxUT1FFUXJPU2RDWVBmNmI1eVZ3eHpUKzRqSzlFdnJSQ2cz?=
 =?utf-8?B?ajhxRFlVVFNtQXo0UGYxbEZ0VzdUamZsSS9kQklxbE1KdHRSbWE3NzA1cmcz?=
 =?utf-8?B?aWhDdHAydzRaZzcrZ0lvOGVldDg3b1pQQTdJekQ0TzFqK1N3TnoweUE2K0hp?=
 =?utf-8?B?d3VqSGJzZ2JjSEk4Ymw5OVh1RDk3NDBlRDcrRHY0Wnk1Mk8veHRQNUtLSG9M?=
 =?utf-8?B?NmpPNzRCV1RndVFkcURHaWkrNHEySk5KaFM1VnpoMXpURlpZbHp4OVJoOUlX?=
 =?utf-8?B?YU4xWDNseEVtSmlmSTBMT2w4M3J4MXR2ODhpRVRyQzhjV3FDQkxnN1hETXpU?=
 =?utf-8?B?b1k1dXVBZ3h3WElDbHN5d1FGQXFIZk9tTjRMMXdaYTM3eU1EVURoNnVIamZq?=
 =?utf-8?B?QlNKM2lGY1FhN3VoV3UrdWZ2bjA5S2FBTHkwdXN4WGRxbmN5NCtIWHE0REUr?=
 =?utf-8?B?SHVQQm1NUzhXdk9FWk52LzF1VmEzWWp2WmR5RHJDWkdFTXFqeGJlVlNITjBI?=
 =?utf-8?B?MWtCM2FIQmx6dXovY2d3SE11eDluZFlQV0pnVUp3TUw0N01QaVJTUzE5eS9P?=
 =?utf-8?B?K3FhVktLckwwTGFoNnY0Ymk4WTRuZFZwaEhEeWdEWXRMdyszNU5oSGpKOU8r?=
 =?utf-8?B?RHlrdE96dy9nNHhTMDRaeWpXYy85UzduUGV4L2pvMXRkWi92SjRUYkZDKzFz?=
 =?utf-8?B?NkNzalJZWnRTNEJpNTJjQWdIUEpsZ29JSzk2RjJBUytIQm9JQ2UzNVRjRkY3?=
 =?utf-8?B?NXNHS1BxcU85Nnl2UFRDWTNsWXljNExocGlUand5NDVSK1h1V1lod3VzZ0Fh?=
 =?utf-8?B?TEVLQ0VYcWVtbTNxVVhneDlsS29PUVo4eTZnTXVXVEhDMjc3WGZDK0pVTGJM?=
 =?utf-8?B?YVFQNTF5ZmVHY1pCS1drbzFITS9NcktNSVhRdW4wdm5ZRjFRblB2SVhMaXMv?=
 =?utf-8?B?UjE3ZVc5Z090SjcxRVp1djRXd2F1SDE2R0d1RU40cTFJSWNqNlIxUTJ1Q1Uy?=
 =?utf-8?B?RlVrVUYwU3E1ZFJVOUsxUE5aMExnK0w1aXRxRVRSbWpJR01pQSs3eldnZWdp?=
 =?utf-8?B?bS8wT052VUhZNHFVdU51cXJ5VzB1M2h1dkRxeXRqSldDajJJN05Yb2Rpa2pl?=
 =?utf-8?B?UkZ4c0hSY3NDeFI2Smt2a1Y5OFB1NWh3OWNwRTJJaEg1clFPbFFPT1ZNaStq?=
 =?utf-8?B?Tk5HU1J4aWVVcEZBQlU4bmIwWFU5bnVOZisyUU13cnNpTlJqdFlpamFHQk9T?=
 =?utf-8?B?U2dNaVdMaElNSUZia3d3ejdubnRobjNWcTRXMWZGdXoweE05NzVrQm95bG03?=
 =?utf-8?B?OGtoRFBQQWF4NjBUYXhsL05BWmRXYVZFSEdqMWpPM3J1aEgzejc4eE9Dd0d1?=
 =?utf-8?B?MDNibmRRWmhpUGg3MGVwelZGVm5wakEyRW0veEVUTmRZNjB1K0tEMmhsOFlC?=
 =?utf-8?B?VVhVanppeS80K2s0SDJvSW5Db3o5blc0VE9lQVF3THJjczNwdGVXdUloWHd1?=
 =?utf-8?B?Tmhpbm0wWThHcm5pNC9rMzNXMGYvRU9YMmtVQkd1MXVIOW9rdWdZTUpxMHc3?=
 =?utf-8?B?NURlQnN3MjFiaG9PRDE2cmd1RWRqdWtGUHpwV2hNbHVqampDZEw0MEtnTDh3?=
 =?utf-8?B?V004eW83czNDT2QzVUZqeG1HUkp5cjhOdThic3o5ZjZoZTkxUkNZcmpSck94?=
 =?utf-8?B?blE9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: ada4afe7-6972-4476-73dc-08dbd70d7a52
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB5089.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2023 16:55:09.0710
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: hBGrTRDiB0zax0WLKU8rhdUyOnUTU2yDA6vXZEDKeOJ2elXmB1+coXT8D92ytfe86DIf8pOaFbpq1hZkTXRUH3bS75O38s78NvUexyDpaMg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB7657
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED
	autolearn=unavailable autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pete.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (pete.vger.email [0.0.0.0]); Fri, 27 Oct 2023 09:55:26 -0700 (PDT)


On 10/26/2023 4:52 PM, Florian Fainelli wrote:
> On 10/26/23 16:23, Jacob Keller wrote:
>>
>>
>> On 10/26/2023 3:45 PM, Florian Fainelli wrote:
>>> Determine whether the PHY can support waking up from the user programmed
>>> network filter, and if it can utilize it.
>>>
>>
>> Here, you're passing through to phy_ethtool_set_rxnfc, basically
>> allowing the lower device to program the wakeup filter if its supported. Ok.
>>
>> This almost feels like it would belong generally in the higher level
>> ethtool code rather than in the driver?
> 
> Agreed, as Doug just pointed out to me, there is still an open question 
> about reconciling the PHY and the MAC RXNFC spaces into a single 
> ethtool_rxnfc structure.
> 
> An ideal goal is to have zero modifications to neither the MAC or the 
> PHY drivers such that they can both work in their own spaces as if they 
> were alone, or combined.
> 
> I suppose that if we get the number of supported rules from the MAC 
> first, and then get the supported number of rules from the PHY next, we 
> could do something like this:
> 
> rule index
> | 0|
> | .| -> MAC rules
> |15|
> |16| -> PHY rule
> 
> and each of the MAC or the PHY {get,set}_rxnfc() operate within a base 
> rule number which is relative to their own space. So the MAC driver 
> would continue to care about its (max..first) - base (0) range, and the 
> PHY would care about (max..first) - base (16).
> 
> Though then the issue is discoverability, how do you know which rule 
> location is backed by which hardware block. We could create an 
> intermediate and inert rule at index 16 for instance that acts as a 
> delimiter?
> 
> Or we could create yet another RX_CLS_LOC_* value that is "special" and 
> can denote whether of the MAC or the PHY we should be targeting 
> whichever is supported, but that does not usually lend itself to being 
> logically ORed with the existing RX_CLS_LOC_* values. WDYT?
> 
> pw-bot: cr

Ah, yea there is a lot of complexity to consider here.

I'm not entirely sure what we should do here. What about extending with
another attribute entirely instead of another bit in RX_CLS_LOC?