Re: Rebase against linux-next tree?
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?
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çoiswrote: > 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?
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?
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
On Wed, Mar 15, 2017 at 12:12:48PM +0100, Bjørn Mork wrote: > Alexander Kapshukwrites: > > >>> 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()
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
Alexander Kapshukwrites: >>> 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
On Wed, Mar 15, 2017 at 12:40 PM, Tobin C. Hardingwrote: > 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
On Wed, Mar 15, 2017 at 12:01:39PM +0200, Alexander Kapshuk wrote: > On Wed, Mar 15, 2017 at 10:31 AM, Tobin C. Hardingwrote: > > 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
On Wed, Mar 15, 2017 at 10:31 AM, Tobin C. Hardingwrote: > 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
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