Linux Framebuffer Layer development
 help / color / mirror / Atom feed
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


  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