All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tingwei Zhang <quic_tingweiz@quicinc.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	<linux-kernel@vger.kernel.org>,
	Trilok Soni <quic_tsoni@quicinc.com>,
	Jinlong Mao <quic_jinlmao@quicinc.com>
Subject: Re: How to pass software configuration to driver built as module in boot up phase
Date: Tue, 31 Oct 2023 18:01:44 +0800	[thread overview]
Message-ID: <b97123bd-7acc-43a7-aff4-e1696511ba05@quicinc.com> (raw)
In-Reply-To: <2023103108-guacamole-neurotic-f59b@gregkh>

On 10/31/2023 2:58 PM, Greg Kroah-Hartman wrote:
> On Tue, Oct 31, 2023 at 10:56:23AM +0800, Tingwei Zhang wrote:
>> On 10/30/2023 7:30 PM, Greg Kroah-Hartman wrote:
>>> On Mon, Oct 30, 2023 at 07:21:48PM +0800, Tingwei Zhang wrote:
>>>> Hi Masami, Greg and Rafael,
>>>>
>>>> I have one driver that needs a bunch to software configuration like 1000
>>>> settings. These settings can be different according to the use case.
>>>
>>> That seems very odd, what type of driver is this?
>> The example use case is below DCC driver which is a DMA engine. It can be
>> configured to read/write registers while whose registers need to be
>> configured by software. It's mainly used to debug device crash issue.
>> https://lore.kernel.org/lkml/cover.1691496290.git.quic_schowdhu@quicinc.com/T/
> 
> Given that no one listened to my last review cycle of that driver, why
> are you asking us again?
> 

There's some change on developer owner of DCC driver. We preparing and 
reviewing the driver internally.  It will be submitted once ready.

>>>> They are required in boot up phase so we can't reply on user space to make
>>>> the configuration.
>>>>
>>>> Boot config is not preferred since we'd like to build that driver as dynamic
>>>> load Kernel module.
>>>>
>>>> Could you let me know if there's any mechanism in Kernel to do that?
>>>
>>> What is wrong with the existing ways of doing this that all other
>>> drivers use?
>> I'm not aware of all the existing ways. Below ways are what I know and they
>> may not be suitable for some reason.
>> 1. Let user space to configure with sysfs/debugfs/ioctl interface. Since we
>> need this configuration to be done in early stage before user space is up.
> 
> I really doubt that you need this before userspace starts, as that's not
> what "device crash" stuff should be dealing with.  That happens after
> init starts, because you have a working kernel (i.e. this is not for
> hardware bringup.)
> 
>> This doesn't work.
> 
> Why do you need this before init?  Specific reasons please.
> 
There are some case that some driver broke Kernel in development phase 
and those bad driver could cause device crash in very early boot up phase.
>> 2. Use device tree to pass the configuration to driver. Since the
>> configuration is software configuration instead of hardware descirption. It
>> doesn't fit in device tree.
>> 3. Boot config or commandline parameter. If the driver is built in, it can
>> work. But it doesn't work for dynamically loadable Kernel module.
> 
> If you have a module, then you can do this after init starts, so you
> are reporting conflicting "requirements" here, which make this
> impossible for us to understand :(

You are correct.  I missed that part. We should already have user space 
up when install the module.

> 
> Please work with the kernel developers at your company to come up with a
> solution for this, you have the experience, do not require the community
> to do your work for you.
> 
> thanks,
> 
> greg k-h

-- 
Thanks,
Tingwei


  reply	other threads:[~2023-10-31 10:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-30 11:21 How to pass software configuration to driver built as module in boot up phase Tingwei Zhang
2023-10-30 11:30 ` Greg Kroah-Hartman
2023-10-31  2:56   ` Tingwei Zhang
2023-10-31  6:58     ` Greg Kroah-Hartman
2023-10-31 10:01       ` Tingwei Zhang [this message]
2023-10-31 10:44         ` Greg Kroah-Hartman
2023-10-30 23:35 ` Masami Hiramatsu
2023-10-31  3:00   ` Tingwei Zhang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b97123bd-7acc-43a7-aff4-e1696511ba05@quicinc.com \
    --to=quic_tingweiz@quicinc.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=quic_jinlmao@quicinc.com \
    --cc=quic_tsoni@quicinc.com \
    --cc=rafael@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.