From: Mauro Carvalho Chehab <mchehab@infradead.org>
To: Markus Rechberger <mrechberger@gmail.com>
Cc: Douglas Schilling Landgraf <dougsland@gmail.com>,
Devin Heitmueller <dheitmueller@kernellabs.com>,
linux-media@vger.kernel.org
Subject: Re: [PATCH] em28xx device mode detection based on endpoints
Date: Mon, 1 Jun 2009 13:31:33 -0300 [thread overview]
Message-ID: <20090601133133.6395a1fb@pedra.chehab.org> (raw)
In-Reply-To: <d9def9db0906010907t52c49c22mc238dedd71b067cd@mail.gmail.com>
Em Mon, 1 Jun 2009 18:07:24 +0200
Markus Rechberger <mrechberger@gmail.com> escreveu:
> >> I spent some time reviewing this patch, and the patch's content does
> >> not seem to match your description of its functionality. Further,
> >> this patch appears to be a combination of a number of several
> >> different changes, rather than being broken into separate patches.
> >>
> >> First off, I totally agree that the analog subsystem should not be
> >> loaded on devices such as em287[0-4]. I was going to do this work
> >> (using the chip id to determine analog support) but just had not had a
> >> chance to doing the necessary testing to ensure it did not break
> >> anything.
> >>
> >> The patch appears to be primarily for devices that are not supported
> >> in the kernel. In fact, the logic as written *only* gets used for
> >> unknown devices. Further, the code that doesn't create the frontend
> >> device has no application in the kernel. All devices currently in the
> >> kernel make use of the dvb frontend interface, so there is no
> >> practical application to loading the driver and setting up the isoc
> >> handlers but blocking access to the dvb frontend device.
> >>
> >> Aside from the code that selectively disables analog support, the
> >> patch only seems to advance compatibility with your userland em28xx
> >> framework while providing no benefit to the in-kernel driver.
> >>
> >> Regarding the possibility of custom firmware, we currently do not have
> >> any devices in the in-kernel driver that make use of custom firmware.
> >> If you could tell me how to check for custom firmware versus the
> >> default vendor firmware, I could potentially do a patch that uses the
> >> vendor registers unless custom firmware is installed, at which point
> >> we could have custom logic (such as using the endpoint definition).
> >> However, given there are no such devices in-kernel, this is not a high
> >> priority as far as I am concerned.
> >>
> >> For what it's worth, I did add an additional patch to allow the user
> >> to disable the 480Mbps check via a modprobe option (to avoid a
> >> regression for any of your existing customers), and I will be checking
> >> in the code to properly compute the isoc size for em2874/em2884 based
> >> on the vendor registers (even though there are currently no supported
> >> devices in the kernel that require it currently). However, I do not
> >> believe the patch you have proposed is appropriate for inclusion in
> >> the mainline kernel.
> >
> > Agree with you Devin.
> >
> > Also, the patch does a lot of changes instead of break it in several
> > patches.
> >
>
> do you want smaller patches?
Markus,
Please break it into smaller patches, being one patch per change. This makes
easier for me to review and for people to comment each one of the addressed issues.
Cheers,
Mauro
prev parent reply other threads:[~2009-06-01 16:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-23 14:04 [PATCH] em28xx device mode detection based on endpoints Markus Rechberger
2009-05-23 14:49 ` Markus Rechberger
2009-05-23 15:05 ` Markus Rechberger
2009-06-01 15:19 ` Devin Heitmueller
2009-06-01 15:32 ` Markus Rechberger
2009-06-01 16:04 ` Douglas Schilling Landgraf
2009-06-01 16:07 ` Markus Rechberger
2009-06-01 16:31 ` Mauro Carvalho Chehab [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=20090601133133.6395a1fb@pedra.chehab.org \
--to=mchehab@infradead.org \
--cc=dheitmueller@kernellabs.com \
--cc=dougsland@gmail.com \
--cc=linux-media@vger.kernel.org \
--cc=mrechberger@gmail.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 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.