All of lore.kernel.org
 help / color / mirror / Atom feed
From: Uri Shkolnik <urishk@yahoo.com>
To: Michael Krufky <mkrufky@linuxtv.org>
Cc: LinuxML <linux-media@vger.kernel.org>,
	Mauro Carvalho Chehab <mchehab@infradead.org>
Subject: Re: [PATCH] [09051_49] Siano: smscore - upgrade firmware loading  engine
Date: Tue, 19 May 2009 11:01:22 -0700 (PDT)	[thread overview]
Message-ID: <15860.11754.qm@web110806.mail.gq1.yahoo.com> (raw)


> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> 
> 
> 
> This patch should not be merged in its current form.
> 
> Linux kernel driver development shall be against the
> current -rc
> kernel, and there is no need to reinvent the
> "REQUEST_FIRMWARE"
> mechanism.
> 
> Furthermore, the changeset introduces more bits of this
> "SMS_HOSTLIB_SUBSYS" -- this requires a binary library
> present on the
> host system.  This completely violates the "no
> multiple APIs in
> kernel" and "no proprietary APIs in kernel" guidelines.
> 
> Uri, what are your plans for this?
> 
> Regards,
> 
> Mike
> 

Mike,

Per discussion with other members of the community, backport are welcome at LinuxTV mercurial (true they are not pass through when up-streaming to the kernel git, but that is per current kernel version anyway ...). 

Regarding the REQUEST_FIRMWARE - with most older kernels, and with some new (I even have such 2.6.27 case), that is the only option available, Please check Motorola (opensource.motorola.com) and Google Android for external examples. Second issue is that when you are using interface like SPI, the hotplug mechanism is degenerated or simply voided. So we can either decide we support only x86 based machines, but if I'm not wrong, I can see lots of TI OMAP (and other ARM) activity lately, so, we may decide to support REQUEST_FIRMWARE...  

Regarding SMS_HOSTLIB_SUBSYS, since it's not defined its... undefined...
The patch replace '#if 0' with '#ifdef SMS_HOSTLIB_SUBSYS' (which is... undefined), so actually no "harm" done, but it make the life of Siano's engineers, and various other who use patches and merges, easier when looking at the code (IMHO strings are better than magic numbers). I simply don't see what's wrong with that.




      

             reply	other threads:[~2009-05-19 18:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-19 18:01 Uri Shkolnik [this message]
2009-05-20  2:41 ` [PATCH] [09051_49] Siano: smscore - upgrade firmware loading engine Mauro Carvalho Chehab
  -- strict thread matches above, loose matches on Subject: below --
2009-05-19 15:43 Uri Shkolnik
2009-05-19 16:23 ` Michael Krufky
2009-06-16 12:39   ` Udi Atar
2009-06-16 16:44     ` Mauro Carvalho Chehab
2009-06-17  8:26       ` Udi Atar

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=15860.11754.qm@web110806.mail.gq1.yahoo.com \
    --to=urishk@yahoo.com \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@infradead.org \
    --cc=mkrufky@linuxtv.org \
    /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.