headers
Grant Likely | 1 Jan 2011 01:49
Picon

Re: [PATCH] spi/spi_topcliff_pch.c Typo change threhold to threshold

On Fri, Dec 31, 2010 at 09:50:31AM -0800, Justin P. Mattock wrote:
> The below patch changes a typo from "threhold" to "threshold".
> Let me know if I missed anything.
> 
> Signed-off-by: Justin P. Mattock <justinmattock <at> gmail.com>

Applied, thanks.

g.

> 
> ---
>  drivers/spi/spi_topcliff_pch.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/spi/spi_topcliff_pch.c b/drivers/spi/spi_topcliff_pch.c
> index 58e187f..be451e3 100644
> --- a/drivers/spi/spi_topcliff_pch.c
> +++ b/drivers/spi/spi_topcliff_pch.c
>  <at>  <at>  -677,7 +677,7  <at>  <at>  static void pch_spi_set_ir(struct pch_spi_data *data)
>  {
>  	/* enable interrupts */
>  	if ((data->bpw_len) > PCH_MAX_FIFO_DEPTH) {
> -		/* set receive threhold to PCH_RX_THOLD */
> +		/* set receive threshold to PCH_RX_THOLD */
>  		pch_spi_setclr_reg(data->master, PCH_SPCR,
>  				   PCH_RX_THOLD << SPCR_TFIC_FIELD,
>  				   ~MASK_TFIC_SPCR_BITS);
>  <at>  <at>  -685,7 +685,7  <at>  <at>  static void pch_spi_set_ir(struct pch_spi_data *data)
>  		pch_spi_setclr_reg(data->master, PCH_SPCR,
(Continue reading)

Permalink | Reply | 0 comments |
headers
George Spelvin | 1 Jan 2011 01:51

Where are the semantics of MSC_SCAN & MSC_RAW input events defined?

I'm trying to rework the ati-remote.c driver to use the input layer
better, such as supporting keyboard remapping.

And I'm finding documentation on the input layer... lacking.  What's the
point of these two event types?  Should I emit either or both when someone
presses a button?  Does it matter if the button has an EV_KEY mapping?

If I should generate multiple input events for one keypress, what order
should they be in?

I notice that atkbd.c generates MSC_SCAN, then EV_KEY.
But Documentation/laptops/thinkpad-acpi.txt says
"A Hot key is mapped to a single input layer EV_KEY event, possibly
followed by an EV_MSC MSC_SCAN event."

I notice there was a proposed patch to fix this in 2007:
http://www.mail-archive.com/linux-input <at> atrey.karlin.mff.cuni.cz/msg00482.html

This recommends generating EV_KEY/KEY_UNKNOWN events for unfamiliar keys,
which atkbd.c (probably the most-used input handler) does not do.

The other question is that the ATI remote retransmits scan codes while
they key is held down, and key-up has to be inferred via a timeout.
Should I generate an MSC_SCAN event for each true reception, or only
for the synthesized key events?

I have a few other questions about the input layer:
- Should I fill in the input_id with the BUS_USB and the
  device's idVendor, idProduct, and bcdDevice?
- What should I put in the input->phys and input->uniq fields?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Igor M. Liplianin | 1 Jan 2011 10:57
Picon
Favicon

Re: [PATCH 04/18] xc5000: add support for DVB-C tuning.

В сообщении от 1 января 2011 11:43:28 автор Benny Amorsen написал:
> It is always good to see more DVB-C devices supported... Do you happen
> to know some devices which have DVB-C support and use this chip?
> 
> 
> /Benny
See next patch ...

--

-- 
Igor M. Liplianin
Microsoft Windows Free Zone - Linux used for all Computing Tasks
Permalink | Reply | 0 comments |
headers
Robert P. J. Day | 1 Jan 2011 12:18
Picon
Gravatar

Re: is there a fix for ubuntu with intel GPU booting to blank screen?

On Fri, 31 Dec 2010, Maxim Levitsky wrote:

> On Fri, 2010-12-31 at 12:01 -0500, Robert P. J. Day wrote:
> > On Fri, 31 Dec 2010, Maxim Levitsky wrote:
> >
> > ... snip related to i915 blank screen issues ...
> >
> > > Since you know how to compile kernel, and even have a close working
> > > version, you really should just bisect the bug.
> > >
> > > Bisection is a built-in in the git binary search that allows you to
> > > find the first commit that introduced the bug.
> > >
> > > For example, quick google gives,
> > > http://www.kernel.org/pub/software/scm/git-core/docs/v1.0.13/howto/isolate-bugs-with-bisect.txt
> >
> >   oh, i know how to do bisection but, to be frank, i just don't have
> > the time.  i'm under a brutal deadline for some billable work and,
> > even if i had the time, i suspect that when i eventually tracked down
> > the commit, i probably wouldn't really appreciate what i was looking
> > at, anyway.

> You truly underestimate this. Having commit that broke things points
> perfectly at the issue. Then, developers can even just revert the
> offending commit until it is understood why it breaks stuff.

  one of the difficulties (if i'm reading this correctly) is that the
issue isn't even reliably reproducible.  a number of people who have
reported this claim that *sometimes* the system boots properly but
it's hit and miss, so it's not even clear you can bisect
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bart Van Assche | 1 Jan 2011 13:51
Picon
Favicon

[PATCH] kobject: Add missing format attribute specifications

Several functions in <linux/kobject.h> accept printf-style arguments.
Some of these functions have been annotated with a format attribute
declaration while others have not been annotated. Add a format attribute
specification where it is missing.

Signed-off-by: Bart Van Assche <bvanassche <at> acm.org>
Cc: "Greg Kroah-Hartman" <gregkh <at> suse.de>

---
 include/linux/kobject.h |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/include/linux/kobject.h b/include/linux/kobject.h
index 8f6d121..15e82c1 100644
--- a/include/linux/kobject.h
+++ b/include/linux/kobject.h
 <at>  <at>  -85,11 +85,13  <at>  <at>  static inline const char *kobject_name(const struct kobject *kobj)
 extern void kobject_init(struct kobject *kobj, struct kobj_type *ktype);
 extern int __must_check kobject_add(struct kobject *kobj,
 				    struct kobject *parent,
-				    const char *fmt, ...);
+				    const char *fmt, ...)
+	__attribute__((format(printf, 3, 4)));
 extern int __must_check kobject_init_and_add(struct kobject *kobj,
 					     struct kobj_type *ktype,
 					     struct kobject *parent,
-					     const char *fmt, ...);
+					     const char *fmt, ...)
+	__attribute__((format(printf, 4, 5)));
(Continue reading)

Permalink | Reply | 2 comments |
headers
Igor M. Liplianin | 1 Jan 2011 14:44
Picon
Gravatar

Re: [PATCH 14/18] cx25840: Fix subdev registration in cx25840-core.c

В сообщении от 1 января 2011 14:58:30 автор Andy Walls написал:
> Igor,
> 
> The proper fix is here:
> 
> https://patchwork.kernel.org/patch/376612/
> 
> So, NAK on your particular patch.
So, it is safe to skip my patch.
Mauro, please skip it.

> 
> Mauro,
> 
> I do not see the above patch at linux next.  And I couldn't find it in your
> kernel.org tree.  What is its status?
> 
> This fixes a regression that is known to break cx23885 hardware
> initialization and can break ivtv hardware initialization.
> 
> Regards,
> Andy
> 
> "Igor M. Liplianin" <liplianin <at> me.by> wrote:
> >On my system, cx23885 based card reports default volume value above 70000.
> >So, register cx25840 subdev fails. Although, the card don't have a/v
> >inputs it needs a/v firmware to be loaded.
> >
> >Signed-off-by: Igor M. Liplianin <liplianin <at> netup.ru>
> >---
(Continue reading)

Permalink | Reply | 0 comments |
headers
Justin P. Mattock | 1 Jan 2011 15:53
Picon

Re: [PATCH 03/15]drivers:staging:rtl8187se:r8180_hw.h Typo change diable to disable.

On 01/01/2011 01:09 AM, Dan Carpenter wrote:
> On Fri, Dec 31, 2010 at 11:43:30PM -0800, Justin P. Mattock wrote:
>> On 12/31/2010 10:48 PM, Finn Thain wrote:
>>>> -/*  BIT[8-9] is for SW Antenna Diversity. Only the value EEPROM_SW_AD_ENABLE means enable, other
values are diable.					*/
>>>> +/*  BIT[8-9] is for SW Antenna Diversity. Only the value EEPROM_SW_AD_ENABLE means enable, other
values are disabled.					*/
>>>
>>> I think, "other values disable" was what you meant?
>>>
>>> Finn
>>>
>>>>   #define EEPROM_SW_AD_MASK			0x0300
>>>>   #define EEPROM_SW_AD_ENABLE			0x0100
>>>>
>>>>
>>>
>>
>> no! I changed it to disabled to make it proper..
>
> Finn is obviously right, but maybe a compromise would be:
>
> Only the value EEPROM_SW_AD_ENABLE means "enable", other values mean
> "disable".
>
> regards,
> dan carpenter
>

ahh.. I see what you your saying now.. alright let me send this out that
(Continue reading)

Permalink | Reply | 0 comments |

Gmane