public inbox for linux-staging@lists.linux.dev
 help / color / mirror / Atom feed
From: Ruben Wauters <rubenru09@aol.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>,
	Teddy Wang <teddy.wang@siliconmotion.com>,
	Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>,
	linux-fbdev@vger.kernel.org,  linux-staging@lists.linux.dev,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/8] staging: sm250fb: remove USE_HW_I2C check
Date: Fri, 18 Apr 2025 12:42:05 +0100	[thread overview]
Message-ID: <ec791e981505d3c8e1d14e6d68eb616ffa4aea71.camel@aol.com> (raw)
In-Reply-To: <2025041836-debug-unstopped-9a88@gregkh>

On Fri, 2025-04-18 at 12:33 +0200, Greg Kroah-Hartman wrote:
> On Thu, Apr 17, 2025 at 08:02:49PM +0100, Ruben Wauters wrote:
> > Removes the USE_HW_I2C check and function defines in
> > ddk750_sii164.c.
> > 
> > The software equivalents were never used due to
> > USE_HW_I2C being defined just before the ifdef, meaning
> > the hardware versions were always used.
> > 
> > The define names were also triggering checkpatch.pl's
> > camel case check.
> > 
> > Signed-off-by: Ruben Wauters <rubenru09@aol.com>
> > 
> > ---
> > 
> > I am somewhat unsure whether this is the way to go or
> > the correct way would be to add an option/opportunity for
> > the software version to be used. Currently the hardware
> > version is always used, but I am unsure if there ever even
> > would be a case where you would want to use the software
> > version over the hardware version.
> 
> Then the code can be added back, not an issue.
> 
> But you forgot this same check in
> drivers/staging/sm750fb/ddk750_hwi2c.c, right?

This check can indeed be removed I suppose, might be worth also
removing the USE_DVICHIP checks also, especially when defined

There's also a USE_HW_I2C check in ddk750.h, which defines which header
to use, however I'm somewhat unsure exactly what the best way to go
about addressing that is, since it's not defined before including it
does make me wonder whether the HW files are even used at all.

Something about this seems entirely wrong to me, again I don't have the
hardware to test, but why would SW files be used when the HW files work
fine? Is it intended that the HW files are used instead? it's a bit
inconsistent, especially since in ddk750_sii164.c the HW ones are
explicitly used over the SW ones
Why is the SW files preferred in sm750_hw.c then?
I believe this is something of an oversight and the files should
probably use the HW ones instead of the SW ones.

I am curious to know your thoughts on this (and anyone else's)

> Also, what about removing the sm750_sw_i2c_write_reg() and other
> functions that are now never referenced?  Can you add that to this
> patch
> series?  A single series that just removes the use of USE_HW_I2C and
> the
> now unneeded functions would be best, as it's not really a "coding
> style" fix, but rather a code cleanup thing, right?

I will create a separate patch series for removing unneeded code, since
it does look like a lot more code removal might be needed than I
originally thought.

> thanks,
> 
> greg k-h

  reply	other threads:[~2025-04-18 11:52 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20250417190302.13811-1-rubenru09.ref@aol.com>
2025-04-17 19:02 ` [PATCH 0/8] staging: sm750fb: cleanup ddk750_sii164 Ruben Wauters
2025-04-17 19:02   ` [PATCH 1/8] staging: sm250fb: remove USE_HW_I2C check Ruben Wauters
2025-04-18 10:33     ` Greg Kroah-Hartman
2025-04-18 11:42       ` Ruben Wauters [this message]
2025-04-17 19:02   ` [PATCH 2/8] staging: sm750fb: rename gDviCtrlChipName Ruben Wauters
2025-04-18 10:36     ` Greg Kroah-Hartman
2025-04-18 11:45       ` Ruben Wauters
2025-04-18 12:09         ` Greg Kroah-Hartman
2025-04-17 19:02   ` [PATCH 3/8] staging: sm750fb: rename vendorID to vendor_id Ruben Wauters
2025-04-18 10:37     ` Greg Kroah-Hartman
2025-04-17 19:02   ` [PATCH 4/8] staging: sm750fb: rename sii164_init_chip params Ruben Wauters
2025-04-17 19:02   ` [PATCH 5/8] staging: sm750fb: rename sii164_set_power's param Ruben Wauters
2025-04-18 10:34     ` Greg Kroah-Hartman
2025-04-17 19:02   ` [PATCH 6/8] staging: sm750fb: rename sii164SelectHotPlugDetectionMode Ruben Wauters
2025-04-17 19:02   ` [PATCH 7/8] staging: sm750fb: rename detectReg to detect_reg Ruben Wauters
2025-04-17 19:02   ` [PATCH 8/8] staging: sm750fb: rename hotPlugValue to hot_plug_value Ruben Wauters
2025-04-18 10:38     ` Greg Kroah-Hartman

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=ec791e981505d3c8e1d14e6d68eb616ffa4aea71.camel@aol.com \
    --to=rubenru09@aol.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=sudip.mukherjee@codethink.co.uk \
    --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