Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Message-ID: <382c4fae-95c5-af26-5d54-fa7ae7422b37@kernel.org>
Date:   Fri, 25 Mar 2022 12:36:20 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.5.0
Subject: Re: [PATCH v1 1/4] usb: host: export symbols for xhci hooks usage
Content-Language: en-US
To:     Jung Daehwan <dh10.jung@samsung.com>
Cc:     Mathias Nyman <mathias.nyman@intel.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "open list:USB XHCI DRIVER" <linux-usb@vger.kernel.org>,
        open list <linux-kernel@vger.kernel.org>,
        Howard Yen <howardyen@google.com>,
        Jack Pham <jackp@codeaurora.org>,
        Puma Hsu <pumahsu@google.com>,
        "J . Avila" <elavila@google.com>,
        "chihhao . chen" <chihhao.chen@mediatek.com>, sc.suh@samsung.com,
        cpgs@samsung.com, cpgsproxy5@samsung.com
References: <1646375038-72082-1-git-send-email-dh10.jung@samsung.com>
 <CGME20220304062617epcas2p2084161966aaa66d07f4c25720ec18088@epcas2p2.samsung.com>
 <252651381.41646375583002.JavaMail.epsvc@epcpadp4>
 <b33d8497-d6d5-18e2-93a9-e0564a84c1c5@kernel.org>
 <1983025922.01648006681661.JavaMail.epsvc@epcpadp4>
 <105eaeec-d77e-b0eb-86ad-a88c7446ca98@kernel.org>
 <1295226194.41648172284403.JavaMail.epsvc@epcpadp4>
From:   Krzysztof Kozlowski <krzk@kernel.org>
In-Reply-To: <1295226194.41648172284403.JavaMail.epsvc@epcpadp4>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 25/03/2022 02:28, Jung Daehwan wrote:
> On Wed, Mar 23, 2022 at 10:41:23AM +0100, Krzysztof Kozlowski wrote:
>> On 23/03/2022 03:58, Jung Daehwan wrote:
>>> On Mon, Mar 07, 2022 at 10:59:06AM +0100, Krzysztof Kozlowski wrote:
>>>> On 04/03/2022 07:23, Daehwan Jung wrote:
>>>>> Export symbols for xhci hooks usage:
>>>>> 	xhci_ring_free
>>>>> 	- Allow xhci hook to free xhci_ring.
>>>>
>>>> Instead of copying-pasting the name of function, please explain why do
>>>> you need these symbols exported.
>>>>
>>>> The "Why" is actually one of most important questions, because "what is
>>>> this patch doing" we can easily see...
>>>>
>>>>>
>>>>> 	xhci_get_slot_ctx
>>>>> 	- Allow xhci hook to get slot_ctx from the xhci_container_ctx
>>>>> 	  for getting the slot_ctx information to know which slot is
>>>>> 	  offloading and compare the context in remote subsystem memory
>>>>> 	  if needed.
>>>>>
>>>>
>>>>
>>>> Best regards,
>>>> Krzysztof
>>>>
>>>
>>> Hi Krzysztof
>>>
>>> xhci_ring_free has been removed from v3..
>>> The reason why I want to export is for managing vendor specific ring.
>>> I want to alloc and free vendor specific ring on specific address.
>>> It's done with xhci hooks.
>>
>> It's better, but still does not explain why these have to be exported.
>> Please mention where are these hooks going to be. Where are they
>> implemented. I actually expect all of these exports to be used in your
>> patchset.
>>
>> Best regards,
>> Krzysztof
>>
> 
> OK. How about adding call stack like below?
> 
> xhci_free_endpoint_ring -> xhci_vendor_free_transfer_ring(xhck hooks
> ops) -> xhci_ring_free

What I would like to see is high level explanation, why do you need
these functions exported. Such call trace does not answer this, because
you do not need to export functions just to call the. You need to export
them for modules, so this means that some modules (which - need names)
will be using these functions. Three or four sentences are usually
enough to explain it.


Best regards,
Krzysztof