Re: [PATCH 3/3] drivers/speakup: Fix style and coding warnings

> On 03 July 2018 at 08:31 Tamir Suliman wrote: > +++ b/drivers/staging/speakup/keyhelp.c > @@ -167,7 +167,7 @@ int spk_handle_help(struct vc_data *vc, u_char type, > u_char ch, u_short key) > synth_printf("%s\n", spk_msg_get(MSG_HELP_INFO)); > build_key_data(); /*

Re: [PATCH 3/3] drivers/speakup: Fix style and coding warnings

> On 03 July 2018 at 08:31 Tamir Suliman wrote: > +++ b/drivers/staging/speakup/keyhelp.c > @@ -167,7 +167,7 @@ int spk_handle_help(struct vc_data *vc, u_char type, > u_char ch, u_short key) > synth_printf("%s\n", spk_msg_get(MSG_HELP_INFO)); > build_key_data(); /*

Re: [PATCH v3 3/8] staging: rtl8192u: User memset to initialize memory, instead of loop.

> On 25 June 2018 at 13:36 John Whitmore wrote: > > > On Mon, Jun 25, 2018 at 12:06:30PM +0300, Andy Shevchenko wrote: > > On Sun, Jun 24, 2018 at 6:34 PM, John Whitmore > > wrote: > > > Replaced memory initialising loop with memset, as suggested by Andy > > > Shevchenko > > > > > > >

Re: [PATCH v3 3/8] staging: rtl8192u: User memset to initialize memory, instead of loop.

> On 25 June 2018 at 13:36 John Whitmore wrote: > > > On Mon, Jun 25, 2018 at 12:06:30PM +0300, Andy Shevchenko wrote: > > On Sun, Jun 24, 2018 at 6:34 PM, John Whitmore > > wrote: > > > Replaced memory initialising loop with memset, as suggested by Andy > > > Shevchenko > > > > > > >

Re: [PATCH] staging: speakup: refactor synths array to use a list

> On 18 June 2018 at 09:46 Samuel Thibault wrote: > > > Justin Skists, le lun. 18 juin 2018 09:41:44 +0100, a ecrit: > > > On 18 June 2018 at 06:34 Gregory Nowak wrote: > > > With /sys/accessibility/speakup/synth set to bns, I am getting output > > >

Re: [PATCH] staging: speakup: refactor synths array to use a list

> On 18 June 2018 at 09:46 Samuel Thibault wrote: > > > Justin Skists, le lun. 18 juin 2018 09:41:44 +0100, a ecrit: > > > On 18 June 2018 at 06:34 Gregory Nowak wrote: > > > With /sys/accessibility/speakup/synth set to bns, I am getting output > > >

Re: [PATCH] staging: speakup: refactor synths array to use a list

> On 18 June 2018 at 06:34 Gregory Nowak wrote: > > > On Tue, Jun 12, 2018 at 08:31:06AM +0200, Samuel Thibault wrote: > > The load/unload is about the module itself, i.e. modprobe speakup_bns ; > > modprobe speakup_soft, switch between them, then rmmod speakup_bns ; > > speakup_soft or the

Re: [PATCH] staging: speakup: refactor synths array to use a list

> On 18 June 2018 at 06:34 Gregory Nowak wrote: > > > On Tue, Jun 12, 2018 at 08:31:06AM +0200, Samuel Thibault wrote: > > The load/unload is about the module itself, i.e. modprobe speakup_bns ; > > modprobe speakup_soft, switch between them, then rmmod speakup_bns ; > > speakup_soft or the

Re: [PATCH] staging: speakup: refactor synths array to use a list

On Wed, Jun 06, 2018 at 03:26:28PM +0200, Samuel Thibault wrote: > Hello, > > Justin Skists, le lun. 04 juin 2018 10:52:12 +0100, a ecrit: > > The synths[] array is a collection of synths acting like a list. > > There is no need for synths to be an array, so refactor synths[

Re: [PATCH] staging: speakup: refactor synths array to use a list

On Wed, Jun 06, 2018 at 03:26:28PM +0200, Samuel Thibault wrote: > Hello, > > Justin Skists, le lun. 04 juin 2018 10:52:12 +0100, a ecrit: > > The synths[] array is a collection of synths acting like a list. > > There is no need for synths to be an array, so refactor synths[

Re: staging: rtl8192e: Series of coding style changes

> On 06 June 2018 at 12:39 John Whitmore wrote: > Again these are just some simple coding style changes to the file, so nothing > of importance. If it keeps grumpy maintainers happy, then it's of great importance! :-) Justin

Re: staging: rtl8192e: Series of coding style changes

> On 06 June 2018 at 12:39 John Whitmore wrote: > Again these are just some simple coding style changes to the file, so nothing > of importance. If it keeps grumpy maintainers happy, then it's of great importance! :-) Justin

[PATCH] staging: speakup: refactor synths array to use a list

-by: Justin Skists --- drivers/staging/speakup/spk_types.h | 2 ++ drivers/staging/speakup/synth.c | 40 ++--- 2 files changed, 15 insertions(+), 27 deletions(-) diff --git a/drivers/staging/speakup/spk_types.h b/drivers/staging/speakup/spk_types.h index 3e082dc3d45c

[PATCH] staging: speakup: refactor synths array to use a list

-by: Justin Skists --- drivers/staging/speakup/spk_types.h | 2 ++ drivers/staging/speakup/synth.c | 40 ++--- 2 files changed, 15 insertions(+), 27 deletions(-) diff --git a/drivers/staging/speakup/spk_types.h b/drivers/staging/speakup/spk_types.h index 3e082dc3d45c

Re: [PATCH 2/6] staging: android: Clean up license identifiers

> On 14 May 2018 at 14:29 Dan Carpenter wrote: > > > On Sun, May 06, 2018 at 06:13:24PM -0700, Nathan Chancellor wrote: > > Add the identifiers when missing and fix the ones already present > > according to checkpatch.pl. > > > > Signed-off-by: Nathan Chancellor

Re: [PATCH 2/6] staging: android: Clean up license identifiers

> On 14 May 2018 at 14:29 Dan Carpenter wrote: > > > On Sun, May 06, 2018 at 06:13:24PM -0700, Nathan Chancellor wrote: > > Add the identifiers when missing and fix the ones already present > > according to checkpatch.pl. > > > > Signed-off-by: Nathan Chancellor > > --- > >

[PATCH] staging: lustre: lnet: add static to libcfs_dev declaration

Add a static prefix to the declaration for libcfs_dev. This would fix the following sparse warning: drivers/staging/lustre/lnet/libcfs/module.c:317:19: warning: symbol 'libcfs_dev' was not declared. Should it be static? Signed-off-by: Justin Skists <justin.ski...@juzza.co.uk> --- d

[PATCH] staging: lustre: lnet: add static to libcfs_dev declaration

Add a static prefix to the declaration for libcfs_dev. This would fix the following sparse warning: drivers/staging/lustre/lnet/libcfs/module.c:317:19: warning: symbol 'libcfs_dev' was not declared. Should it be static? Signed-off-by: Justin Skists --- drivers/staging/lustre/lnet/libcfs

[PATCH] Documentation/process/posting: wrap text at 80 cols

Trivial patch to adjust the text formatting to wrap at 80 columns. No actual content has changed. Signed-off-by: Justin Skists <justin.ski...@juzza.co.uk> --- Documentation/process/5.Posting.rst | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/Documen

[PATCH] Documentation/process/posting: wrap text at 80 cols

Trivial patch to adjust the text formatting to wrap at 80 columns. No actual content has changed. Signed-off-by: Justin Skists --- Documentation/process/5.Posting.rst | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/Documentation/process/5.Posting.rst b

Re: [PATCH] staging: lustre: Fix unneeded byte-ordering cast

On 20 March 2018 at 01:06, NeilBrown <ne...@suse.com> wrote: > On Sat, Mar 17 2018, Justin Skists wrote: > >> Fix sparse warning: >> >> CHECK drivers/staging//lustre/lnet/lnet/acceptor.c >> drivers/staging//lustre/lnet/lnet/acceptor.c:243:30: w

Re: [PATCH] staging: lustre: Fix unneeded byte-ordering cast

On 20 March 2018 at 01:06, NeilBrown wrote: > On Sat, Mar 17 2018, Justin Skists wrote: > >> Fix sparse warning: >> >> CHECK drivers/staging//lustre/lnet/lnet/acceptor.c >> drivers/staging//lustre/lnet/lnet/acceptor.c:243:30: warning: cast to >> restrict

[PATCH] staging: lustre: Fix unneeded byte-ordering cast

-by: Justin Skists <j.ski...@gmail.com> --- drivers/staging/lustre/lnet/lnet/acceptor.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/lustre/lnet/lnet/acceptor.c b/drivers/staging/lustre/lnet/lnet/acceptor.c index fb478e20e204..13e981781b9a 100644 --- a/drivers/s

[PATCH] staging: lustre: Fix unneeded byte-ordering cast

-by: Justin Skists --- drivers/staging/lustre/lnet/lnet/acceptor.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/lustre/lnet/lnet/acceptor.c b/drivers/staging/lustre/lnet/lnet/acceptor.c index fb478e20e204..13e981781b9a 100644 --- a/drivers/staging/lustre/lnet/lnet

Where did my symbols go?

Hi. Sorry if this is an idiotic question, especially if it's one worthy of slapping! I've been trying to set my system up to have multiple linux "test-bed" setups on one drive - That was done easily, I thought. However, my Caldera (freebie eDesktop 2.4) distribution won't insmod my driver,

RE: Linux kernel modules development in C++

But but but.. wasn't the very first C++ compilers really just a preprocessor into standard C? I went to a advanced C course, a year or so ago, and the guy showed us how to write OO code in C that went a little beyond everyday encapsulation. At the end, he told us that that was the type of code

RE: cPCI development

Am I right in assumming that 2.2.14 (as from RH6.2) supports cPCI? Or do I need to start developing on 2.4? I really do need to do some research into this, if I knew where to start. I need some docs! (either paper, URL, or the straight-jacket kind) Justin. > -Original Message- > From:

RE: cPCI development

Am I right in assumming that 2.2.14 (as from RH6.2) supports cPCI? Or do I need to start developing on 2.4? I really do need to do some research into this, if I knew where to start. I need some docs! (either paper, URL, or the straight-jacket kind) Justin. -Original Message- From:

cPCI development

Hi. I'm about to embark on some compact-PCI driver development for Linux and I was wondering where I can find some info. Is there any difference between PCI and cPCI development on Linux? URLs would be great! Or, if this is the wrong list for driver development issues, a pointer to the correct

RE: PCI-DMA

Standard book: Try "Linux Device Drivers" by Alessandro Rubini (O'Reilly)... Justin > -Original Message- > From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]] > > hi, > can anybody tell, where to find information about dma usage by pci > -devices in linux > - To unsubscribe from

RE: PCI-DMA

Standard book: Try "Linux Device Drivers" by Alessandro Rubini (O'Reilly)... Justin -Original Message- From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]] hi, can anybody tell, where to find information about dma usage by pci -devices in linux - To unsubscribe from this list: