Grant Likely | 1 Jan 01:49 2011
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)

George Spelvin | 1 Jan 01:51 2011

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)

George Spelvin | 1 Jan 02:03 2011

Re: still nfs problems [Was: Linux 2.6.37-rc8]

> ...and your point would be that an exponentially increasing addition to
> the existing number of tests is an acceptable tradeoff in a situation
> where the >99.999999999999999% case is that of sane servers with no
> looping? I don't think so...

1) Look again; it's O(1) work per entry, or O(n) work for an n-entry
   directory.  And O(1) space.  With very small constant factors, and
   very little code.  The only thing exponentially increasing is the
   interval at which you save the current cookie for future comparison.
2) You said it *was* a problem, so it seemed worth presenting a
   practical solution.  If you don't think it's worth it, I'm not
   going to disagree.  But it's not impossible, or even difficult.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Trond Myklebust | 1 Jan 02:18 2011
Picon

Re: still nfs problems [Was: Linux 2.6.37-rc8]

On Fri, 2010-12-31 at 20:03 -0500, George Spelvin wrote: 
> > ...and your point would be that an exponentially increasing addition to
> > the existing number of tests is an acceptable tradeoff in a situation
> > where the >99.999999999999999% case is that of sane servers with no
> > looping? I don't think so...
> 
> 1) Look again; it's O(1) work per entry, or O(n) work for an n-entry
>    directory.  And O(1) space.  With very small constant factors, and
>    very little code.  The only thing exponentially increasing is the
>    interval at which you save the current cookie for future comparison.
> 2) You said it *was* a problem, so it seemed worth presenting a
>    practical solution.  If you don't think it's worth it, I'm not
>    going to disagree.  But it's not impossible, or even difficult.

Yes. I was thinking about it this morning (after coffee).

One variant on those algorithms that might make sense here is to save
the current cookie each time we see that the result of a cookie search
is a filp->f_pos offset < the current filp->f_pos offset. That means we
will in general only detect the loop after going through an entire
cycle, but that should be sufficient...

Trond

--

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@...
(Continue reading)

Serge E. Hallyn | 1 Jan 05:45 2011

Re: [RFC 4/5] user namespaces: allow killing tasks in your own or child userns

Quoting Eric W. Biederman (ebiederm <at> xmission.com):
> "Serge E. Hallyn" <serge <at> hallyn.com> writes:
> 
> > Quoting Eric W. Biederman (ebiederm <at> xmission.com):
> >> > --- a/kernel/signal.c
> >> > +++ b/kernel/signal.c
> >> >  <at>  <at>  -659,11 +686,7  <at>  <at>  static int check_kill_permission(int sig, struct siginfo *info,
> >> >  	cred = current_cred();
> >> >  	tcred = __task_cred(t);
> >> Nit pick  you don't need to compute cred and tcred here now.
> >
> > Just to make sure I understand right: you mean wait until after the
> > same_thread_group() check to save calculation in that case, right?
> 
> I mean cred and tcred are only use in kill_ok_by_cred.
> So we can eliminate those two variables from check_kill_permission.

Thanks for the review.  Here is an updated version.

Subject: [PATCH 4/5] allow killing tasks in your own or child userns

Changelog:
	Dec 8: Fixed bug in my check_kill_permission pointed out by
	       Eric Biederman.
	Dec 13: Apply Eric's suggestion to pass target task into kill_ok_by_cred()
	        for clarity
	Dec 31: address comment by Eric Biederman:
		don't need cred/tcred in check_kill_permission.

Signed-off-by: Serge E. Hallyn <serge.hallyn <at> canonical.com>
(Continue reading)

Serge E. Hallyn | 1 Jan 05:47 2011

Re: [RFC 5/5] user namespaces: Allow ptrace from non-init user namespaces

Quoting Eric W. Biederman (ebiederm <at> xmission.com):
> "Serge E. Hallyn" <serge <at> hallyn.com> writes:
> 
> > ptrace is allowed to tasks in the same user namespace according to
> > the usual rules (i.e. the same rules as for two tasks in the init
> > user namespace).  ptrace is also allowed to a user namespace to
> > which the current task the has CAP_SYS_PTRACE capability.
> 
> The uid equality check below is broken.

Thanks for the review, Eric.  Updated version appended.  Assuming there
are no big problems with this version, I hope to do setuid/setgid and
start the simplest vfs access controls next.

Subject: [PATCH 5/5] Allow ptrace from non-init user namespaces

ptrace is allowed to tasks in the same user namespace according to
the usual rules (i.e. the same rules as for two tasks in the init
user namespace).  ptrace is also allowed to a user namespace to
which the current task the has CAP_SYS_PTRACE capability.

Changelog:
	Dec 31: Address feedback by Eric:
		. Correct ptrace uid check
		. Rename may_ptrace_ns to ptrace_capable
		. Also fix the cap_ptrace checks.

Signed-off-by: Serge E. Hallyn <serge.hallyn <at> canonical.com>
---
 include/linux/capability.h     |    2 +
(Continue reading)

George Spelvin | 1 Jan 06:44 2011

Re: still nfs problems [Was: Linux 2.6.37-rc8]

>> 1) Look again; it's O(1) work per entry, or O(n) work for an n-entry
>>    directory.  And O(1) space.  With very small constant factors,

> Yes. I was thinking about it this morning (after coffee).

Thank you for the second look.

> One variant on those algorithms that might make sense here is to save
> the current cookie each time we see that the result of a cookie search
> is a filp->f_pos offset < the current filp->f_pos offset. That means we
> will in general only detect the loop after going through an entire
> cycle, but that should be sufficient...

All of these low-overhead algorithms can take a couple of loop iterations
before they detect it; their job is to achieve a reasonably low constant
factor in time using O(1) space.

The worst case for the power-of-two algorithm is when the loop is n = 2^k+1
items long.  When you get to item 2^(k+1), you'll be comparing to item
2^k, which is a mismatch.  Then you'll save the cookie from 2^(k+1)
and have to go to 2^(k+1) + 2^k + 1, or about 3*n, before detecting
it.

I don't consider this a problem, because it wastes a few seconds of
computer time, to be followed by wasting a few hours trying to pass
a bug report upstream about the broken NFS server...

I don't quite follow how your proposed variant works.  Pardon my ignorance
of NFS, but is the f->pos something that comes from the server, or
something that is synthesized locally?  Obviously, if you keep a record
(Continue reading)

Finn Thain | 1 Jan 07:48 2011
Picon

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


On Thu, 30 Dec 2010, Justin P. Mattock wrote:

> The below patch fixes a typo "diable" to "disable". Please let me know if this 
> is correct or not.
> 
> Signed-off-by: Justin P. Mattock <justinmattock <at> gmail.com>
> 
> ---
>  drivers/staging/rtl8187se/r8180_hw.h |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/staging/rtl8187se/r8180_hw.h b/drivers/staging/rtl8187se/r8180_hw.h
> index 3fca144..2911d40 100644
> --- a/drivers/staging/rtl8187se/r8180_hw.h
> +++ b/drivers/staging/rtl8187se/r8180_hw.h
>  <at>  <at>  -554,7 +554,7  <at>  <at> 
>  /* by amy for power save		*/
>  /* by amy for antenna			*/
>  #define EEPROM_SW_REVD_OFFSET 0x3f
> -/*  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
(Continue reading)

Justin P. Mattock | 1 Jan 08:43 2011
Picon

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

On 12/31/2010 10:48 PM, Finn Thain wrote:
>
> On Thu, 30 Dec 2010, Justin P. Mattock wrote:
>
>> The below patch fixes a typo "diable" to "disable". Please let me know if this
>> is correct or not.
>>
>> Signed-off-by: Justin P. Mattock<justinmattock <at> gmail.com>
>>
>> ---
>>   drivers/staging/rtl8187se/r8180_hw.h |    2 +-
>>   1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/staging/rtl8187se/r8180_hw.h b/drivers/staging/rtl8187se/r8180_hw.h
>> index 3fca144..2911d40 100644
>> --- a/drivers/staging/rtl8187se/r8180_hw.h
>> +++ b/drivers/staging/rtl8187se/r8180_hw.h
>>  <at>  <at>  -554,7 +554,7  <at>  <at> 
>>   /* by amy for power save		*/
>>   /* by amy for antenna			*/
>>   #define EEPROM_SW_REVD_OFFSET 0x3f
>> -/*  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
>
(Continue reading)

Dan Carpenter | 1 Jan 10:09 2011
Picon

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

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

Gmane