Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <6059D983.5080306@gmail.com>
Date:   Tue, 23 Mar 2021 14:05:23 +0200
From:   Eli Billauer <eli.billauer@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100907 Fedora/3.0.7-1.fc12 Thunderbird/3.0.7
MIME-Version: 1.0
To:     Greg KH <gregkh@linuxfoundation.org>
CC:     devel@driverdev.osuosl.org, dan.carpenter@oracle.com,
        linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
        arnd@arndb.de
Subject: Re: [PATCH v4 1/2] char: xillybus: Move class-related functions to
 new xillybus_class.c
References: <20210311095033.20956-1-eli.billauer@gmail.com> <20210311095033.20956-2-eli.billauer@gmail.com> <YFc65bvAN3/ZNsww@kroah.com> <6058792C.90801@gmail.com> <YFh7dlY9cntgoLXD@kroah.com>
In-Reply-To: <YFh7dlY9cntgoLXD@kroah.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 22/03/21 13:11, Greg KH wrote:
>
>> XILLYBUS and XILLYBUS_PCIE are currently enabled as M in several Linux
>> distributions. Making them depend on, rather than select XILLYBUS_CLASS is
>> likely to disable the driver in those distributions.
>>      
> That's not an issue here, depends-on will allow those distros to also
> enable this option.
>
> But wait, why is this a separate option at all?  Shouldn't the class
> code just be part of the "core" XILLYBUS code anyway?
>
>    
I'll try to explain the whole picture:

            XILLYBUS_CLASS
               /        \
              |          |
          XILLYBUS   XILLYUSB
       /           \
      |             |
XILLYBUS_PCIE  XILLYBUS_OF

XILLYBUS_CLASS is new and common to all drivers in this group.

XILLYBUS is for drivers based upon memory registers + DMA-based 
interfaces, and it's combined with XILLYBUS_PCIE and/or XILLYBUS_OF. 
XILLYUSB is for the USB variant only.

Or a more detailed, bottom-up outline:

* CONFIG_XILLYBUS_PCIE -> xillybus_pcie.c: Functions related to PCIe.
* CONFIG_XILLYBUS_OF -> xillybus_of.c: Functions related to Xillybus as 
a peripheral on an FPGA / Processor combo chip.
* CONFIG_XILLYBUS -> xillybus_core.c: Functions that are common to the 
two above, mainly access to the peripheral with memory-mapped registers 
and DMA.
* CONFIG_XILLYUSB -> xillyusb.c: The driver for the USB variant, 
accesses the peripheral through the USB framework.
* CONFIG_XILLYBUS_CLASS -> xillybus_class.c: The new module, which 
contains the class and API parts that would otherwise appear both in 
xillybus_core.c and xillyusb.c. Contains utility functions for the two 
latter.

Because XILLYBUS_CLASS is new and "N" by default, making a "depends on" 
relationship means that "make olddefconfig" silently turns off 
CONFIG_XILLYBUS and CONFIG_XILLYBUS_PCIE. That's a bug: Adding a new 
driver shouldn't change anything in the existing configuration.

That's why I had the "select XILLYBUS_CLASS" to begin with: It ensures a 
smooth transition on a kernel upgrade, by adding XILLYBUS_CLASS to 
kernels that had CONFIG_XILLYBUS enabled. Is there another way to 
prevent the said bug, without "select"?

Thanks and regards,
    Eli