Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751501AbdG0BpJ (ORCPT ); Wed, 26 Jul 2017 21:45:09 -0400 Received: from fllnx210.ext.ti.com ([198.47.19.17]:61601 "EHLO fllnx210.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751365AbdG0BpH (ORCPT ); Wed, 26 Jul 2017 21:45:07 -0400 Subject: Re: [PATCH 1/4] can: dev: Add support for limiting configured bitrate To: Oliver Hartkopp , , , , , , , , , References: <20170719233654.25908-1-fcooper@ti.com> <20170719233654.25908-2-fcooper@ti.com> <055c00f5-0775-4e35-309c-0d1c8aa0afdf@ti.com> <20170726200403.GD6873@airbook.vandijck-laurijssen.be> From: Franklin S Cooper Jr Message-ID: <05ca373b-977c-1a59-69fe-c17e5ec4ae75@ti.com> Date: Wed, 26 Jul 2017 20:44:33 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170726200403.GD6873@airbook.vandijck-laurijssen.be> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [128.247.59.33] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1898 Lines: 61 Hi Kurt, On 07/26/2017 03:04 PM, Kurt Van Dijck wrote: > Hi, > > I know my response is late ... > >> Hi Oliver >> On 07/20/2017 02:43 AM, Oliver Hartkopp wrote: >>> Hi Franklin, >>> >>> On 07/20/2017 01:36 AM, Franklin S Cooper Jr wrote: >>> >>>> +#ifdef CONFIG_OF >>>> +void of_transceiver_is_fixed(struct net_device *dev) >>>> +{ >>> >>> (..) >>> >>>> +} >>>> +EXPORT_SYMBOL(of_transceiver_is_fixed); >>>> +#endif >>> >>> I'm not sure about the naming here. >>> >>> As this is a CAN transceiver related option it should be named accordingly: > > I contest the the name too: > 1) the can transceiver isn't fixed at all, it limited to the higher > bitrates. Its "possible" that this subnode may have additional properties beyond bitrates in the future. But your right as of now it is specifically addressing max bit rates. The naming of this function and subnode is based on "fixed-link". So "fixed" is just implying that certain properties can't be changed. > > 2) of_can_transceiver_is_fixed suggests to test if a transceiver is > fixed, it does not suggest to load some properties from the device tree. > of_can_load_transceiver looks way more clear to me. I address this partially in my rev 2 that I've already sent. I'm now using of_can_transceiver_fixed. The fact its of_ already implies it is loading properties from device tree. So I don't think of_can_load_transceiver really makes things clearer. > > That's my opinion. > The important things, like the contents of the functions, look good. You mind throwing your two cents in the thread for my latest patch? Specifically the conversation regarding naming the properties. A couple of people prefer to not use "arbitration" in one of the property names. Currently I believe there are two options on property names that can be used and I'm open to a majority vote on which one to go with. > > Kind regards, > Kurt Van Dijck >