Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
Content-Type:   text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
User-Agent: ALL-INKL Webmail 2.11
In-Reply-To: <20180625123554.dlpgejqmjm7haak4@mwanda>
References: <20180624094245.23741-1-Valentin.Vidic@CARNet.hr> <20180624163138.30976-1-Valentin.Vidic@CARNet.hr><20180625123554.dlpgejqmjm7haak4@mwanda>
Subject: Re: [PATCH v3] staging: pi433: replace simple switch statements
From:   marcus.wolf@smarthome-wolf.de
To:     Valentin.Vidic@CARNet.hr, dan.carpenter@oracle.com
Cc:     gregkh@linuxfoundation.org, devel@driverdev.osuosl.org,
        robsonde@gmail.com, michael.panzlaff@fau.de, hle@owl.eu.com,
        luca@acul.me, linux-kernel@vger.kernel.org,
        marcin.s.ciupak@gmail.com, linux@Wolf-Entwicklungen.de,
        simon@nikanor.nu, joe@perches.com
Message-Id: <20180625132758.D724A2CE0120@dd39320.kasserver.com>
Date:   Mon, 25 Jun 2018 15:27:58 +0200 (CEST)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Dan,

I'd like to mention once more, that the idea of the abstraction was to 
support multiple modules of Hope-RF.
If the decision of the "team" of developer of this driver is, that it 
should be reduced to a Pi433 or RFM69CW driver only, I fully agree, 
that the abstraction layer isn't necessary (tough improving readability).

But if the "team" wants to extend the driver - here I explicitly want to 
Name Marcin Ciupak and Hogo Lefeuvre, both were discussing this with me - 
I highly recommend to keep the abstraction layer.

And once again, I have to announce, that - if noone appears, who wants to 
help me with selling Pi433 - I can't effort to let Pi433 on the market 
longer then end of this year. From this Point of view on long term it 
might be senseless to prepare a Pi433-only driver.

Cheers,
Marcus

Dan Carpenter schrieb am 25.06.2018 14:35:
> I'd still prefer if we just removed this abstraction entirely and used
> OPMODE_MODE_TRANSMIT everywhere instead of bringing "transmit" into it.
> 
> I know that every author thinks their abstraction will definitely be
> useful in the future, but generally kernel style is to remove
> abstractions.
> 
> But I guess this code is an improvement over the original so the patch
> is fine.
> 
> regards,
> dan carpenter
> 
>