Re: Rebase against linux-next tree?

2017-03-15 Thread valdis . kletnieks
On Thu, 16 Mar 2017 10:26:48 +0900, Greg KH said:
> On Tue, Mar 14, 2017 at 07:52:36PM -0600, Perry Hooker wrote:

> > $ git checkout next-20170310

> > What am I doing wrong / where should I go for more info?
>
> linux-next is usually a day or so behind my tree, so maybe there were
> other patches from other developers that caused the conflict.  Try
> linux-next now and see if there still is a conflict or not, and if not,
> rebase and resend the patches.

Stephen Rothwell posted that there won't be any linux-next this week.  Try
on Monday.


pgp40yRul6KDJ.pgp
Description: PGP signature
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: Free Linux/Ubuntu VMs for Kernal Development?

2017-03-15 Thread Praveen Kumar
Hello,

A bit confused with "free Linux/Ubuntu VMs".
Do you mean you looking for VM image ( to directly run  your tests )
or an emulator to create VMs locally and play around.

For the first, I have not tried with. Probably vmware images can be found at :
http://www.osboxes.org/vmware-images/

But, if you are looking for emulators, I would say Xen and Virtualbox.
I use them for most of my development for linux kernel related work
items. To start with, I would suggest you to start with Virtualbox.
Its easy to begin w.r.t. configuration, installation and other items.

Link : https://www.virtualbox.org/

Regards,

~Praveen.

On 14 March 2017 at 15:45, François  wrote:
> On Tue, Mar 14, 2017 at 12:18:33PM +0800, Freeman Zhang wrote:
>> On 3/14/17 12:04 PM, Balaji Barmavat wrote:
>> > Anybody's has any VM's links to download, for practice kernel
>> programming?
>>
>> Well, I am using QEMU system emulator, for it's easier to connect to GDB
>> debugging and itself handles bootloader thing. You can set all things up
>> by one line parameters, really tidy.
>>
>> The disadvantage is that I've been told system running in QEMU is slow,
>> but for kernel programming that wouldn't be the problem, will it?
>>
>> What about others?
>
> Depending on what you're working on, you can also use User Mode Linux
> (UML) [1] which produces a elf, that you can run easily on top of your
> existing linux distro.
> Basically, you have to choose the "um" arch when compiling your kernel.
>
> [1] http://user-mode-linux.sourceforge.net/old/UserModeLinux-HOWTO.html
>
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: Rebase against linux-next tree?

2017-03-15 Thread Greg KH
On Tue, Mar 14, 2017 at 07:52:36PM -0600, Perry Hooker wrote:
> I recently submitted a patch (attached below) that corrects a couple
> of 'sparse' warnings in drivers/staging/rtl8192u/r8192U_dm.c.
> 
> I got this reply back from greg k-h:
> 
> > This patch does not apply to my tree at all :(
> > Please rebase it against linux-next and try again.
> 
> However,  I thought I *was* working off linux-next. This is what I did:
> 
> $ git remote add linux-next
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> $ git fetch linux-next
> $ git fetch --tags linux-next
> $ git remote update
> $ git checkout next-20170310
> $ git apply 0001-staging-rtl8192u-use-__le16_to_cpu-instead-of-cast.patch
> 
> ... and the patch applied ok.
> Just to be sure, I also did this:
> 
> $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> $ git apply 0001-staging-rtl8192u-use-__le16_to_cpu-instead-of-cast.patch
> 
> ... and the patch again applied OK.
> 
> What am I doing wrong / where should I go for more info?

linux-next is usually a day or so behind my tree, so maybe there were
other patches from other developers that caused the conflict.  Try
linux-next now and see if there still is a conflict or not, and if not,
rebase and resend the patches.

If you really want to do a lot of staging tree work, I suggest working
off of my staging-next or staging-testing branch.  Note, sometimes
staging-testing gets rebased, so unless you know how to handle that, I
would stay away from it :)

That's the fun of dealing with a subsystem that gets a few hundred
patches submitted every day, it moves fast...

thanks,

greg k-h

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Rebase against linux-next tree?

2017-03-15 Thread Perry Hooker
I recently submitted a patch (attached below) that corrects a couple
of 'sparse' warnings in drivers/staging/rtl8192u/r8192U_dm.c.

I got this reply back from greg k-h:

> This patch does not apply to my tree at all :(
> Please rebase it against linux-next and try again.

However,  I thought I *was* working off linux-next. This is what I did:

$ git remote add linux-next
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
$ git fetch linux-next
$ git fetch --tags linux-next
$ git remote update
$ git checkout next-20170310
$ git apply 0001-staging-rtl8192u-use-__le16_to_cpu-instead-of-cast.patch

... and the patch applied ok.
Just to be sure, I also did this:

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
$ git apply 0001-staging-rtl8192u-use-__le16_to_cpu-instead-of-cast.patch

... and the patch again applied OK.

What am I doing wrong / where should I go for more info?

Thanks,
Perry

---
 drivers/staging/rtl8192u/r8192U_dm.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_dm.c
b/drivers/staging/rtl8192u/r8192U_dm.c
index 9209aad..33d105d 100644
--- a/drivers/staging/rtl8192u/r8192U_dm.c
+++ b/drivers/staging/rtl8192u/r8192U_dm.c
@@ -2304,9 +2304,9 @@ static void dm_check_edca_turbo(
/*  For Each time updating EDCA
parameter, reset EDCA turbo mode status. */
dm_init_edca_turbo(dev);
u1bAIFS = qos_parameters->aifs[0] *
((mode&(IEEE_G|IEEE_N_24G)) ? 9 : 20) + aSifsTime;
-   u4bAcParam =
(((u32)(qos_parameters->tx_op_limit[0])) <<
AC_PARAM_TXOP_LIMIT_OFFSET)|
-
(((u32)(qos_parameters->cw_max[0])) << AC_PARAM_ECW_MAX_OFFSET)|
-
(((u32)(qos_parameters->cw_min[0])) << AC_PARAM_ECW_MIN_OFFSET)|
+   u4bAcParam =
(((u32)__le16_to_cpu(qos_parameters->tx_op_limit[0])) <<
AC_PARAM_TXOP_LIMIT_OFFSET) |
+
(((u32)__le16_to_cpu(qos_parameters->cw_max[0])) <<
AC_PARAM_ECW_MAX_OFFSET) |
+
(((u32)__le16_to_cpu(qos_parameters->cw_min[0])) <<
AC_PARAM_ECW_MIN_OFFSET) |
((u32)u1bAIFS << AC_PARAM_AIFS_OFFSET);
/*write_nic_dword(dev,
WDCAPARA_ADD[i], u4bAcParam);*/
write_nic_dword(dev, EDCAPARA_BE,  u4bAcParam);

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: pr_debug

2017-03-15 Thread Tobin C. Harding
On Wed, Mar 15, 2017 at 12:12:48PM +0100, Bjørn Mork wrote:
> Alexander Kapshuk  writes:
> 
> >>> On Wed, Mar 15, 2017 at 10:31 AM, Tobin C. Harding  wrote:
> >>> > why does calling pr_debug() with more than one argument cause a sparse
> >>> > warning?
> >>> >
> >>> > drivers/mmc/core/sdio_io.c:70:9: error: unknown field name in 
> >>> > initializer
> >>> >
> >>> > sdio_io.c:70:
> >>> > pr_debug("SDIO: Enabling device %s...\n", sdio_func_id(func));
> ..
> > 'sdio_func_id()' is a macro defined here:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/include/linux/mmc/sdio_func.h?id=refs/tags/v4.11-rc2
> > #define sdio_func_id(f) (dev_name(&(f)->dev))
> 
> 
> So the "func" in that debug call contains a 'struct device'.  Any
> reason why the pr_debug() shouldn't be converted to something like
> 
>  dev_dbg(>dev, "SDIO: Enabling device...\n");

Good point Bjørn, thanks. And thank you Alexander for your input. I
fear I may have sent you both on a wild goose chase with the example
that I chose. pr_debug() causes a sparse warning in many instances
when the format string includes format specifiers.

/* this is fine */
pr_debug("some info string");   

/* this often causes Sparse warning */
pr_debug("string with specifier: %d", foo); 

A simple example can be seen by adding this function

void foo(const char *baz)
{
pr_debug("cause Sparse warning - %s\n", baz);
}

To a random driver, and running `make C=2 M=drivers/staging/ks7010`

drivers/staging/ks7010/ks_hostif.c:2702:9: error: unknown field name in 
initializer

For more examples from the kernel tree, running:
$ make -j9 C=2 M=drivers/staging 2>sparse.out

gives many such cases, for example:

drivers/staging/fbtft/fbtft-core.c:472:17: error: unknown field name in 
initialize
drivers/staging/media/bcm2048/radio-bcm2048.c:2596:17: error: unknown field 
name in initializer
drivers/staging/dgnc/dgnc_tty.c:1274:17: error: unknown field name in 
initializer

Also dev_debug causes the same sparse warning at times, for example:

drivers/staging/comedi/comedi_fops.c:352:17: error: unknown field name in 
initialize

if (s->busy) {
dev_dbg(dev->class_dev,
"subdevice is busy, cannot resize buffer\n");
return -EBUSY;
}

And 2 more example instances of dev_debug:
drivers/staging/comedi/drivers/das16.c:578:25: error: unknown field name in 
initialize
drivers/staging/dgnc/dgnc_tty.c:1274:17: error: unknown field name in 
initializer

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


[mm subsystem] A question about function page_table_range_init_count()

2017-03-15 Thread Hao Lee
Hi, all

I encounter a problem when I read the source code of kernel 4.9.9.

In arch/x86/mm/init_32.c, at line 125 [1], there is a function named
page_table_range_init_count(...). I have analyzed some codes and find its
two parameters are PKMAP_BASE and FIXADDR_START.

Between Line 141 and Line 150, there is a for loop and I don't know what it
means, especially Line 144-Line147.

Could someone can give me some tips. Thanks a lot!

Here is the code:
[1]  http://lxr.free-electrons.com/source/arch/x86/mm/init_32.c?v=4.9#L125

Hao Lee
Thanks.
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: pr_debug

2017-03-15 Thread Bjørn Mork
Alexander Kapshuk  writes:

>>> On Wed, Mar 15, 2017 at 10:31 AM, Tobin C. Harding  wrote:
>>> > why does calling pr_debug() with more than one argument cause a sparse
>>> > warning?
>>> >
>>> > drivers/mmc/core/sdio_io.c:70:9: error: unknown field name in initializer
>>> >
>>> > sdio_io.c:70:
>>> > pr_debug("SDIO: Enabling device %s...\n", sdio_func_id(func));
..
> 'sdio_func_id()' is a macro defined here:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/include/linux/mmc/sdio_func.h?id=refs/tags/v4.11-rc2
> #define sdio_func_id(f) (dev_name(&(f)->dev))


So the "func" in that debug call contains a 'struct device'.  Any
reason why the pr_debug() shouldn't be converted to something like

 dev_dbg(>dev, "SDIO: Enabling device...\n");

?



Bjørn

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: pr_debug

2017-03-15 Thread Alexander Kapshuk
On Wed, Mar 15, 2017 at 12:40 PM, Tobin C. Harding  wrote:
> On Wed, Mar 15, 2017 at 12:01:39PM +0200, Alexander Kapshuk wrote:
>> On Wed, Mar 15, 2017 at 10:31 AM, Tobin C. Harding  wrote:
>> > why does calling pr_debug() with more than one argument cause a sparse
>> > warning?
>> >
>> > drivers/mmc/core/sdio_io.c:70:9: error: unknown field name in initializer
>> >
>> > sdio_io.c:70:
>> > pr_debug("SDIO: Enabling device %s...\n", sdio_func_id(func));
>> >
>> > What can we do about this?
>> >
>> > thanks,
>> > Tobin.
>> >
>> > ___
>> > Kernelnewbies mailing list
>> > Kernelnewbies@kernelnewbies.org
>> > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>> What is the version of the sources you are using?
>
> I'm usually working of gregKH's staging tree using branch staging-next
> and/or staging-testing
>
> thanks,
> Tobin.

'sdio_func_id()' is a macro defined here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/include/linux/mmc/sdio_func.h?id=refs/tags/v4.11-rc2
#define sdio_func_id(f) (dev_name(&(f)->dev))

The 'func' parameter passed into 'sdio_func_id()' is a pointer to
'struct device dev', which is a member of 'struct sdio_func' defined
here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/include/linux/mmc/sdio_func.h?id=refs/tags/v4.11-rc2

Based on my understanding of the error message you got, the error must
lie in code that initialises 'func' to a field name of a struct that
isn't known at compile time.

At this stage, I'm not sure how to identify the code where the faulty
initialisation takes place.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: pr_debug

2017-03-15 Thread Tobin C. Harding
On Wed, Mar 15, 2017 at 12:01:39PM +0200, Alexander Kapshuk wrote:
> On Wed, Mar 15, 2017 at 10:31 AM, Tobin C. Harding  wrote:
> > why does calling pr_debug() with more than one argument cause a sparse
> > warning?
> >
> > drivers/mmc/core/sdio_io.c:70:9: error: unknown field name in initializer
> >
> > sdio_io.c:70:
> > pr_debug("SDIO: Enabling device %s...\n", sdio_func_id(func));
> >
> > What can we do about this?
> >
> > thanks,
> > Tobin.
> >
> > ___
> > Kernelnewbies mailing list
> > Kernelnewbies@kernelnewbies.org
> > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> 
> What is the version of the sources you are using?

I'm usually working of gregKH's staging tree using branch staging-next
and/or staging-testing

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: pr_debug

2017-03-15 Thread Alexander Kapshuk
On Wed, Mar 15, 2017 at 10:31 AM, Tobin C. Harding  wrote:
> why does calling pr_debug() with more than one argument cause a sparse
> warning?
>
> drivers/mmc/core/sdio_io.c:70:9: error: unknown field name in initializer
>
> sdio_io.c:70:
> pr_debug("SDIO: Enabling device %s...\n", sdio_func_id(func));
>
> What can we do about this?
>
> thanks,
> Tobin.
>
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

What is the version of the sources you are using?

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


pr_debug

2017-03-15 Thread Tobin C. Harding
why does calling pr_debug() with more than one argument cause a sparse
warning?

drivers/mmc/core/sdio_io.c:70:9: error: unknown field name in initializer

sdio_io.c:70:
pr_debug("SDIO: Enabling device %s...\n", sdio_func_id(func));

What can we do about this?

thanks,
Tobin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies