From: Dan Carpenter <error27@gmail.com>
To: Onish Sharma <neharora23587@gmail.com>
Cc: sudipm.mukherjee@gmail.com, teddy.wang@siliconmotion.com,
gregkh@linuxfoundation.org, linux-fbdev@vger.kernel.org,
linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] staging: sm750fb: remove unused variable
Date: Fri, 29 May 2026 13:39:11 +0300 [thread overview]
Message-ID: <ahlszyY6Nd9ANz-X@stanley.mountain> (raw)
In-Reply-To: <20260529101242.10189-1-neharora23587@gmail.com>
On Fri, May 29, 2026 at 03:42:42PM +0530, Onish Sharma wrote:
> Remove the set_all_eng_off flag and its associated cleanup logic.
> The variable is redundant as the hardware should be initialized to a
> known state regardless of prior usage.
>
> Suggested-by: Dan Carpenter <error27@gmail.com>
> Signed-off-by: Onish Sharma <neharora23587@gmail.com>
> ---
Sorry, miscommunication. This breaks the driver. This is also a bit
more involved than I thought...
There are two structs:
struct init_status {
ushort power_mode;
/* below three clocks are in unit of MHZ*/
ushort chip_clk;
ushort mem_clk;
ushort master_clk;
ushort setAllEngOff;
ushort reset_memory;
};
And struct initchip_param. The initchip_param is exactly the same but
with all the struct members renamed and comments added. They have to
match because we cast back and forth.
Why do we have two different struct that have to be the same? You might
think it is for API, but as near as I can see that is not the case.
Maybe it was at some point? We should get rid of one struct. Which
everyone is API is the one we should keep. If neither is API then get
rid of init_status and keep initchip_param.
After that we can talk about getting rid of setAllEngOff/set_all_eng_off.
regards,
dan carpenter
next prev parent reply other threads:[~2026-05-29 10:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <ahlXYIqzu4O5-u9J@stanley.mountain>
2026-05-29 10:12 ` [PATCH v2] staging: sm750fb: remove unused variable Onish Sharma
2026-05-29 10:39 ` Dan Carpenter [this message]
2026-05-29 10:44 ` Dan Carpenter
2026-05-29 11:25 ` neha arora
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=ahlszyY6Nd9ANz-X@stanley.mountain \
--to=error27@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=neharora23587@gmail.com \
--cc=sudipm.mukherjee@gmail.com \
--cc=teddy.wang@siliconmotion.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox