headers
Wolfram Sang | 2 Nov 2009 13:13
Picon
Favicon

Re: [spi-devel-general] [PATCH] trivial: some fixes in spi documentation

Hi,

the typo fixes look good, still...

On Fri, Oct 30, 2009 at 07:28:14PM -0200, Thadeu Lima de Souza Cascardo wrote:
> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo <at> holoscopio.com>
> ---
>  Documentation/spi/spi-summary |    8 ++++----
>  1 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/spi/spi-summary b/Documentation/spi/spi-summary
> index deab51d..607aa97 100644
> --- a/Documentation/spi/spi-summary
> +++ b/Documentation/spi/spi-summary
>  <at>  <at>  -121,7 +121,7  <at>  <at>  active.  So the master must set the clock to inactive before selecting
>  a slave, and the slave can tell the chosen polarity by sampling the
>  clock level when its select line goes active.  That's why many devices
>  support for example both modes 0 and 3:  they don't care about polarity,
> -and alway clock data in/out on rising clock edges.
> +and always clock data in/out on rising clock edges.
>  
>  
>  How do these driver programming interfaces work?
>  <at>  <at>  -236,7 +236,7  <at>  <at>  And SOC-specific utility code might look something like:
>  		struct mysoc_spi_data *pdata2;
>  
>  		pdata2 = kmalloc(sizeof *pdata2, GFP_KERNEL);
> -		*pdata2 = pdata;
> +		*pdata2 = *pdata;
(Continue reading)

Permalink | Reply | 1 comment |
headers
Frederic Weisbecker | 2 Nov 2009 15:15
Picon

Re: [PATCH 1/8] SGI x86_64 UV: Add limit console output function

On Mon, Oct 26, 2009 at 10:55:31AM -0700, Mike Travis wrote:
>
>
> Frederic Weisbecker wrote:
>> On Fri, Oct 23, 2009 at 06:37:44PM -0500, Mike Travis wrote:
>>> With a large number of processors in a system there is an excessive amount
>>> of messages sent to the system console.  It's estimated that with 4096
>>> processors in a system, and the console baudrate set to 56K, the startup
>>> messages will take about 84 minutes to clear the serial port.
>>>
>>> This patch adds (for SGI UV only) a kernel start option "limit_console_
>>> output" (or 'lco' for short), which when set provides the ability to
>>> temporarily reduce the console loglevel during system startup.  This allows
>>> informative messages to still be seen on the console without producing
>>> excessive amounts of repetious messages.
>>>
>>> Note that all the messages are still available in the kernel log buffer.
>>
>>
>>
>> Well, this problem does not only concerns SGI UV but all boxes with a large
>> number of cpus.
>>
>> Also, instead of adding the same conditionals in multiple places to solve
>> the same problem (and that may even expand if we go further the SGI UV case,
>> for example with other archs cpu up/down events), may be can you centralize,
>> institutionalize this issue by using the existing printk mechanisms.
>>
>> I mean, may be that could be addressed by adding a new printk
>> level flag, and then associate the desired filters against it.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thadeu Lima de Souza Cascardo | 2 Nov 2009 17:54

Re: [spi-devel-general] [PATCH] trivial: some fixes in spi documentation

On Mon, Nov 02, 2009 at 01:13:34PM +0100, Wolfram Sang wrote:
> Hi,
> 
> the typo fixes look good, still...
> 
> On Fri, Oct 30, 2009 at 07:28:14PM -0200, Thadeu Lima de Souza Cascardo wrote:
> > Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo <at> holoscopio.com>
> > ---
> >  Documentation/spi/spi-summary |    8 ++++----
> >  1 files changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/Documentation/spi/spi-summary b/Documentation/spi/spi-summary
> > index deab51d..607aa97 100644
> > --- a/Documentation/spi/spi-summary
> > +++ b/Documentation/spi/spi-summary
> >  <at>  <at>  -121,7 +121,7  <at>  <at>  active.  So the master must set the clock to inactive before selecting
> >  a slave, and the slave can tell the chosen polarity by sampling the
> >  clock level when its select line goes active.  That's why many devices
> >  support for example both modes 0 and 3:  they don't care about polarity,
> > -and alway clock data in/out on rising clock edges.
> > +and always clock data in/out on rising clock edges.
> >  
> >  
> >  How do these driver programming interfaces work?
> >  <at>  <at>  -236,7 +236,7  <at>  <at>  And SOC-specific utility code might look something like:
> >  		struct mysoc_spi_data *pdata2;
> >  
> >  		pdata2 = kmalloc(sizeof *pdata2, GFP_KERNEL);
> > -		*pdata2 = pdata;
> > +		*pdata2 = *pdata;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jiri Kosina | 3 Nov 2009 16:08
Picon

Re: [PATCH] Fix fs/debugfs/inode.c typos

On Sat, 31 Oct 2009, Alberto Bertogli wrote:

> Signed-off-by: Alberto Bertogli <albertito <at> blitiri.com.ar>
> ---
>  fs/debugfs/inode.c |    6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
[ ... ]
>  <at>  <at>  -195,8 +195,8  <at>  <at>  static int debugfs_create_by_name(const char *name, mode_t mode,
>   *        this file.
>   *
>   * This is the basic "create a file" function for debugfs.  It allows for a
> - * wide range of flexibility in createing a file, or a directory (if you
> - * want to create a directory, the debugfs_create_dir() function is
> + * wide range of flexibility in creating a file, or a directory (if you want
> + * to create a directory, the debugfs_create_dir() function is
>   * recommended to be used instead.)
>   *
>   * This function will return a pointer to a dentry if it succeeds.  This

I haven't found this one fixed in current -next, so I have put it into 
trivial queue.

Thanks,

--

-- 
Jiri Kosina
SUSE Labs, Novell Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ali Gholami Rudi | 8 Nov 2009 16:59
Picon

[PATCH] trivial: fix checking socket() in net tstamp example


Signed-off-by: Ali Gholami Rudi <ali <at> rudi.ir>
---
 .../networking/timestamping/timestamping.c         |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Documentation/networking/timestamping/timestamping.c b/Documentation/networking/timestamping/timestamping.c
index a7936fe..bab619a 100644
--- a/Documentation/networking/timestamping/timestamping.c
+++ b/Documentation/networking/timestamping/timestamping.c
 <at>  <at>  -370,7 +370,7  <at>  <at>  int main(int argc, char **argv)
 	}

 	sock = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP);
-	if (socket < 0)
+	if (sock < 0)
 		bail("socket");

 	memset(&device, 0, sizeof(device));
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 4 comments |
headers
Patrick Ohly | 8 Nov 2009 18:24
Picon
Favicon
Gravatar

Re: [PATCH] trivial: fix checking socket() in net tstamp example

On Sun, 2009-11-08 at 15:59 +0000, Ali Gholami Rudi wrote:
> Signed-off-by: Ali Gholami Rudi <ali <at> rudi.ir>
> ---
>  .../networking/timestamping/timestamping.c         |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/Documentation/networking/timestamping/timestamping.c b/Documentation/networking/timestamping/timestamping.c
> index a7936fe..bab619a 100644
> --- a/Documentation/networking/timestamping/timestamping.c
> +++ b/Documentation/networking/timestamping/timestamping.c
>  <at>  <at>  -370,7 +370,7  <at>  <at>  int main(int argc, char **argv)
>  	}
>  
>  	sock = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP);
> -	if (socket < 0)
> +	if (sock < 0)

Argh, of course you are right. FWIW, acknowledged.

--

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ali Gholami Rudi | 8 Nov 2009 18:57
Picon

Re: [PATCH] trivial: fix checking socket() in net tstamp example

Hi Patrick,

Patrick Ohly <patrick.ohly <at> intel.com> wrote:
> > --- a/Documentation/networking/timestamping/timestamping.c
> > +++ b/Documentation/networking/timestamping/timestamping.c
> >  <at>  <at>  -370,7 +370,7  <at>  <at>  int main(int argc, char **argv)
> >  	}
> >  
> >  	sock = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP);
> > -	if (socket < 0)
> > +	if (sock < 0)
> 
> Argh, of course you are right. FWIW, acknowledged.

By the way, I tried igb hardware timestamp but HWTSTAMP_FILTER_ALL works
almost like HWTSTAMP_FILTER_PTP_*.  Isn't it supposed to timestamp all
of the incoming packets?  Maybe there is something wrong with my test
setup?

Thanks,
Ali
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Emilio G. Cota | 8 Nov 2009 21:19
Favicon
Gravatar

What's the state of the TX timestamping?

[dropped trivial <at> kernel.org since this is not relevant to them]

by the way Patrick,

A few months ago I tried to implement TX timestamping for a card
I was working on [1]. I wasn't quite successful (sorry can't be more
explicit, I haven't touched it since then) and thought the reason
was that the implementation was half-baked because David reverted
it--I got to that conclusion after reading this thread in
linux-net ("TX time stamping"):

http://thread.gmane.org/gmane.linux.network/121378/

Could you please tell me what the state of TX timestamping is?
Did David revert it or not? I can't find a revert commit.

Thanks,
		Emilio

[1] http://www.ohwr.org/twiki/bin/view/OHR/WhiteRabbit/WhiteRabbit

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Pavel Machek | 9 Nov 2009 09:53
Picon

periodic fsck was Re: [patch] ext2/3: document conditions when reliable operation is possible

On Wed 2009-08-26 14:02:48, Theodore Tso wrote:
> On Wed, Aug 26, 2009 at 06:43:24AM -0700, david <at> lang.hm wrote:
> >>>
> >>> as the ext3 authors have stated many times over the years, you still need
> >>> to run fsck periodicly anyway.
> >>
> >> Where is that documented?
> >
> > linux-kernel mailing list archives.
> 
> Probably from some 6-8 years ago, in e-mail postings that I made.  My
> argument has always been that PC-class hardware is crap, and it's a

Well, in SUSE11-or-so, distro stopped period fscks, silently :-(. I
believed that it was really bad idea at that point, but because I
could not find piece of documentation recommending them, I lost the
argument.
									Pavel

--

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 11 comments |
headers
Pavel Machek | 9 Nov 2009 11:50
Picon

Re: raid is dangerous but that's secret (was Re: [patch] ext2/3: document conditions when reliable operation is possible)

Hi!

> >> If you have a specific bug in MD code, please propose a patch.
> >
> > Interesting. So, what's technically wrong with the patch below?
> >
> 
> You mean apart from ".... that high highly undesirable ...." ??
>                                ^^^^^^^^^^^
> 

Ok, I still believe kernel documentation should be ... well... in
kernel, not in LWN article, so I fixed the patch according to your
comments.

Signed-off-by: Pavel Machek <pavel <at> ucw.cz>

diff --git a/Documentation/filesystems/dangers.txt b/Documentation/filesystems/dangers.txt
new file mode 100644
index 0000000..14d0324
--- /dev/null
+++ b/Documentation/filesystems/dangers.txt
 <at>  <at>  -0,0 +1,21  <at>  <at> 
+There are storage devices that have highly undesirable properties when
+they are disconnected or suffer power failures while writes are in
+progress; such devices include flash devices and degraded DM/MD RAID
+4/5/6 (*) arrays.  These devices have the property of potentially
+corrupting blocks being written at the time of the power failure, and
+worse yet, amplifying the region where blocks are corrupted such that
+additional sectors are also damaged during the power failure.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane