public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: "Németh Márton" <nm127@freemail.hu>
To: Jean-Francois Moine <moinejf@free.fr>
Cc: Hans de Goede <hdegoede@redhat.com>,
	V4L Mailing List <linux-media@vger.kernel.org>,
	Thomas Kaiser <thomas@kaiser-linux.li>,
	Theodore Kilgore <kilgota@auburn.edu>,
	Kyle Guinn <elyk03@gmail.com>
Subject: Re: [PATCH 00/21] gspca pac7302/pac7311: separate the two drivers
Date: Sun, 01 Nov 2009 22:59:06 +0100	[thread overview]
Message-ID: <4AEE04AA.1040308@freemail.hu> (raw)
In-Reply-To: <20091101095259.67122ef1@tele>

Jean-Francois Moine wrote:
> On Sun, 01 Nov 2009 00:13:10 +0100
> Németh Márton <nm127@freemail.hu> wrote:
> 
>> the following patchset refactores the Pixart PAC7311 subdriver. The
>> current situation is that the code contains a lot of decisions
>> like this:
>>
>>     if (sd->sensor == SENSOR_PAC7302) {
>>         ... do this ...
>>     } else {
>>         ... do something else ...
>>     }
>>
>> The sensor type is determined using the USB Vendor ID and Product
>> ID which means that the decisions shown are not really necessary.
>>
>> The goal of the patchset is to have a PAC7302 and a PAC7311 subdriver
>> which have the benefit that there is no decision necessary on sensor
>> type at runtime. The common functions can be extracted later but this
>> would be a different patchset.
> 
> Splitting the pac7311 subdriver is a good idea, but I don't like your
> patchset: a lot of changes (function prefixes) are nullified by the
> last patch. I'd better like only one change for the pac7302 creation
> and a second one for the interface change of pac_find_sof() in
> pac_common.h (BTW, this file could now be compiled separately).

Hello Jef,

thank you for the feedback, I'll try to send a patch set wich contains
bigger steps. I hope the separation will be not a too big step and won't
make it too difficult to bisect any possible problem I might introduce
with this change. But hope for the best and imagine the easy way when
no regression was introduced.

I am also thinking about finding the common functions which can be
compiled separately either in a helper module or to gspca_main maybe.
But first I focus on the pac7302/pac7311 separation.

	Márton Németh

      reply	other threads:[~2009-11-01 21:59 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-31 23:13 [PATCH 00/21] gspca pac7302/pac7311: separate the two drivers Németh Márton
2009-11-01  8:52 ` Jean-Francois Moine
2009-11-01 21:59   ` Németh Márton [this message]

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=4AEE04AA.1040308@freemail.hu \
    --to=nm127@freemail.hu \
    --cc=elyk03@gmail.com \
    --cc=hdegoede@redhat.com \
    --cc=kilgota@auburn.edu \
    --cc=linux-media@vger.kernel.org \
    --cc=moinejf@free.fr \
    --cc=thomas@kaiser-linux.li \
    /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