Re: Seeking help addressing maintainer objections
Ian Pilcher writes:
> It's not absolutely needed, but it does make it easier to unlink an LED
> from all devices by using the names of the symlinks in the LED's
> linked_devices directory, which will be kernel names.
Yes, I agree that things are much easier if those names can be fed
directly into the unlink attribute. And even better if the names in the
linked_devices directory actually matched what you used to link them.
So why not go for "major:minor" everywhere? I.e for link, unlink and
also for the symlinks in linked_devices.
>> And if file name with symlink resolution really is a problem, then why
>> can't you use the major:minor for link/unlink? That's easy for
>> userspace to look up whether the input is a device path or a sysfs path.
>> And it avoids having to wait for an unrelated and unnecessary device
>> path creation.
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/core/ledtrig-usbport.c
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/core/ledtrig-usbport.c?id=0f247626cbbfa2010d2b86fdee652605e084e248
>
> Personally, I don't think that using file paths is a problem, and it
> can be useful. ("/dev/vg_root/lv_root" is probably more useful than
> "dm-0".) OTOH, "sda" is slightly simpler than "/dev/sda", so I think
> that the ideal situation would be to have both interfaces available.
>
> I did propose using device numbers. I never received a response from
> the maintainer.
I believe that's how most maintainers work unless the proposal was in
patch form :-)
Bjørn
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Seeking help addressing maintainer objections
Ian Pilcher writes: > The maintainer of the LEDs subsystem considers this interface to be > "crazy", but he has not suggested any alternative.[3] I read a strong suggestion that one of the unlink interfaces is dropped. You should probably read "crazy" as "unjustified". > (I have not been able to find any existing example of configuring > many-to-many relationships via sysfs.) There's at least one such example, hidden under drivers/usb: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/core/ledtrig-usbport.c See the initial commit for justification and some of the background for the choices made: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/core/ledtrig-usbport.c?id=0f247626cbbfa2010d2b86fdee652605e084e248 > The second problem is the use of device file paths (including symbolic > link resolution), rather than kernel names, when creating associations. > This limitation exists because the block subsystem does not provide an > API to open a block device by its kernel name; only device file paths > and device numbers (major & minor) are supported. So this explains why you can't have link_dev_by_path. It still does not explain why you need unlink_dev_by_name. And if file name with symlink resolution really is a problem, then why can't you use the major:minor for link/unlink? That's easy for userspace to look up whether the input is a device path or a sysfs path. And it avoids having to wait for an unrelated and unnecessary device path creation. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/core/ledtrig-usbport.c https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/core/ledtrig-usbport.c?id=0f247626cbbfa2010d2b86fdee652605e084e248 Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Using net/wan/hdlc with serdev
Ayush Singh writes: > But well, I am not sure how to create an HDLC frame? Is there a helper > that creates HDLC frame skbuff for me? Or maybe the hdlc > implementation is simply not designed to be used for Asynchronous > framing [1]. It would be great if someone could explain how to use > this HDLC module or point to some resource I might have missed. I don't know anything at all about this subject, but I believe the wan HDLC stuff is sync only. Noting that the ppp driver does all the async framing internally. And interleaved with ppp specific stuff, so probably not re-usable even if exported. Ref ppp_async_encode() in drivers/net/ppp/ppp_async.c I assume it would have used a shared implementation if there was one. But I could be wrong... Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Vendor driver vs Kernel, which one gets priority?
Do Hak Yong writes: > Hello kernel experts, > > I have a few questions about the priority of kernel drivers and third party > drivers. > > If I install a third party vendor driver, which has the same module name as > kernel provides, for example, Qlogic driver has the same module name as > third party driver(qla2xxx). > > The questions are: > > Q1. Which driver has higher priority and which driver will be used? will > there any be problems? See depmod.d(5). Unless overridden by config, modules in /lib/modules/$(uname -r)/updates have priority over other modules. This can be used to replace kernel modules with a third party driver. The third party driver could also use a startup script to forcibly replace already loaded modules. > Q2. How to control which driver the os will use? If the file names are identical, then use the "updates" directory or configure another location to have priority over the kernel modules. If the file names are different, then you can blacklist the kernel module to make sure the third party module is the only one available for auto-loading. See modprobe.d(5) > Q3. What if the updated kernel installed and provied higher driver version > than third party? Which one will be used then? The default is to consider only the modules in /lib/modules/$(uname -r) Any third party module must be updated along with the kerne. Or copied into the new location if binary compatible. But that's not likely in general. > I think third party drivers have more precedence that kernel drivers refer > to below Red Hat KB, but I'm not sure which one will be used when the > kernel has updated. > > https://access.redhat.com/solutions/176213 Redhat uses a more complex depmod configuration than default. You should probably ask them about their setup. Or just look at the config in /etc/depmod.d/*.conf Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: efivars
Ruben Safir writes: > I really just want to know what efi varriables exist and why we have a > sys file for them The "why" question is answered here: https://www.kernel.org/doc/Documentation/filesystems/efivarfs.rst The "what" question doesn't have a short answer. If you don't want the long one, then that's fine. You don't need to worry about efi variables. Leave them alone and they will do you no harm. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: efivars
Ruben Safir writes: > OS's shouldn't need anything from a boot loader. Why do you need a bootloader then? I'd suggest playing with embedded devices for a while. Their boot chain is usually much simpler than on PC hardware. There you can really get a feeling of how easy and decoupled stuff could have been. Load a kernel directly to some location in memory and just jump there. Then try to expand a bit by reading the kernel from some specific flash device, or even network. Maybe trying to make the kernel do the right thing depending on where it was booted from. Or add a file system to the flash. Etc. Maybe you even want some way to configure the bootloader from the OS? Add all the features you take for granted on PC hardware. I think you will find that the OS has to be aware of some of the stuff the bootloader does. And that many of the features depend on the OS communicating with the bootloader somehow. Both ways. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How to print __u128_t in kernel?
Philipp Hortmann writes:
> I do like this example:
> https://lwn.net/Articles/745261/
>
> ...
> pr_err("%llx%llx\n", (u64) (val >> 64), (u64) val);
> pr_err("%llx%llx\n", (u64) (v >> 64), (u64) v);
> ...
>
This will produce the wrong output unless at least one of bit 60 - 63 is
set and have a confusing leading zero unless one of the upper 64 bits is
set.
Running this test:
#include
#include
int main(int argc, char **argv)
{
__uint128_t foo;
if (argc < 3)
return -1;
foo = (__uint128_t)strtoull(argv[1], NULL, 0) << 64 | strtoull(argv[2],
NULL, 0);
fprintf(stderr, "foo=0x%llx%llx\n", (__uint64_t) (foo >> 64),
(__uint64_t) foo);
fprintf(stderr, "foo=0x%016llx%016llx\n", (__uint64_t) (foo >> 64),
(__uint64_t) foo);
return 0;
}
Produces:
bjorn@miraculix:~$ /tmp/x 1 0
foo=0x10
foo=0x0001
bjorn@miraculix:~$ /tmp/x 1 2
foo=0x12
foo=0x00010002
bjorn@miraculix:~$ /tmp/x 0 2
foo=0x02
foo=0x0002
Bjørn
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How to switch between installed kernel and developed kernel
Gidi Gal writes: > I am new to kernel development, currently working on > https://kernelnewbies.org/FirstKernelPatch. I reached the step "Install > your changes" in "Modifying a driver on native Linux". I would like to > separate my developed kernel and my installed kernel and to switch between > the two in order to test my changes. I am not sure that my tutorial > explains how to do that. If you have a link that proposes a workflow for > this request (or if my tutorial does explain this workflow and I'm missing > the exact paragraph that does that) please let me know. The answer depends on your choice of bootloader, distro etc. But one way to do this is to build a native kernel package for your distro and simply install that like any other package. So instead of make -j2; sudo make modules_install install you'll do somethong like (or maybe give a more explicit version than '*') make -j2 bindeb-pkg; sudo dpkg -i ../linux-image-*.deb or similare with "binrpm-pkg" for the RPM based distros. With this you'll end up with your testing kernel as an additional choice in the bootloader menu, keeping all your previously installed kernels as alternatives. Note that this way of testing is quite slow since you'll rebuild everythng and reboot a bare metal machine. There are easier ways to test many kernel changes, like rebuilding only one module and load it in your running kernel. And there is of course always a very real risk of crashing, and possibly thrashing too... So if you can, you might want to run test your kernels on a virtual machine, or some other test machine, instead of your development machine. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kbuild support for rebuilding a single driver gone?
"Valdis Klētnieks" writes: > On Tue, 07 Jul 2020 14:22:42 +0200, Bjrn Mork said: >> I have "always" tested simple patches by rebuilding just the affected >> driver on whatever kernel I happen to run. Like this: > >> make -C /lib/modules/4.19.0-9-amd64/build M=$(pwd)/drivers/net/usb >> qmi_wwan.ko > > I suspect the problem is that M= is causing everything in that directory to > be > rebuilt, possibly because it points at itself rather than an output directory > elsewhere. > > Because it points at itself, why are you even specifying it, instead of just > saying > make -C /lib/modules/4.19.0-9-amd64/build drivers/net/usb/qmi_wwan.ko Masahiro Yamada fixed the problem immediately after I followed Greg's great advice: https://patchwork.kernel.org/patch/11649263/ Applying that patch locally to the top level Makefile from the Debian linux-headers 5.6 and 5.7 packages fixes the problem for me. So everything will be fine when this eventually trickles down there via stable. > (For that matter, using a 4.19 directory for -C when you're apparently > working with a git tree is probably rather sketchy as well... Yes, sure, that is obviously not something I can, or do, expect to work unconditionally. Let me try to explain why I do that, with the risk of revealing too much of my sloppy methods :-) I like to test stuff myself before acking on anything. And I prefer testing drivers with real hardware if I can spare the time to do that. Nowadays I mostly run some distro kernel, since I don't do much kernel related developement. Building and loading a module or two for the currently running kernel takes a few seconds. Buikding and booting a new kernel takes at least 10 minutes, and often much much more when there are unrelated problems to solve first.. Not to mention the hassle of having to shut down whatever else I was using the "test hardware" (i.e the laptop I am doing all my work on) for. Given this choice I will always try to build on my current kernel first, knowing that it is a best effort thing. If it works - fine. If it doesn't - well, I didn't expect it to. But that will usually result in me cancelling the run test. Now, for the reasons that it works in this case: The usbnet API is pretty stable. There hasn't really been much going on there for ages. Some drivers are actively developed and pick up new features from e.g the net subsystem, like the r8152 ethtool example, but most of them are in maintenance mode and only get occasional fixes and device id additions. The result is that you can copy most of drivers/net/usb from mainline or net-next straight into an old kernel like 4.19. Not sure the lack of new development is a good thing, but it is very convenient ;-) Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kbuild support for rebuilding a single driver gone?
Greg KH writes: > Why not ask on the kbuild mailing list? Because I'm too lazy to look up any list I'm not already subscribed to. And I do feel like a newbie whenever I stumble acroess problems like this one :-) Thanks for the pointer. Question redirected there now. Bjørn (newbie forever) ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Kbuild support for rebuilding a single driver gone?
I have "always" tested simple patches by rebuilding just the affected driver on whatever kernel I happen to run. Like this: bjorn@miraculix:/usr/local/src/git/linux$ make -C /lib/modules/4.19.0-9-amd64/build M=$(pwd)/drivers/net/usb clean make: Entering directory '/usr/src/linux-headers-4.19.0-9-amd64' CLEAN /usr/local/src/git/linux/drivers/net/usb/Module.symvers make: Leaving directory '/usr/src/linux-headers-4.19.0-9-amd64' bjorn@miraculix:/usr/local/src/git/linux$ make -C /lib/modules/4.19.0-9-amd64/build M=$(pwd)/drivers/net/usb qmi_wwan.ko make: Entering directory '/usr/src/linux-headers-4.19.0-9-amd64' CC [M] /usr/local/src/git/linux/drivers/net/usb/qmi_wwan.o MODPOST 1 modules CC /usr/local/src/git/linux/drivers/net/usb/qmi_wwan.mod.o LD [M] /usr/local/src/git/linux/drivers/net/usb/qmi_wwan.ko make: Leaving directory '/usr/src/linux-headers-4.19.0-9-amd64' But this is broken for some reason with recent Debian (bullseye/sid) kernels, based on 5.6 or 5.7 kernels. They will always compile all source files in the directory, even of most of them are not necessary for the requested target: bjorn@miraculix:/usr/local/src/git/linux$ make -C /lib/modules/5.7.0-1-amd64/build M=$(pwd)/drivers/net/usb clean make: Entering directory '/usr/src/linux-headers-5.7.0-1-amd64' CLEAN /usr/local/src/git/linux/drivers/net/usb/Module.symvers make: Leaving directory '/usr/src/linux-headers-5.7.0-1-amd64' bjorn@miraculix:/usr/local/src/git/linux$ make -C /lib/modules/5.7.0-1-amd64/build M=$(pwd)/drivers/net/usb qmi_wwan.ko make: Entering directory '/usr/src/linux-headers-5.7.0-1-amd64' AR /usr/local/src/git/linux/drivers/net/usb/built-in.a CC [M] /usr/local/src/git/linux/drivers/net/usb/catc.o CC [M] /usr/local/src/git/linux/drivers/net/usb/kaweth.o CC [M] /usr/local/src/git/linux/drivers/net/usb/pegasus.o CC [M] /usr/local/src/git/linux/drivers/net/usb/rtl8150.o CC [M] /usr/local/src/git/linux/drivers/net/usb/r8152.o CC [M] /usr/local/src/git/linux/drivers/net/usb/hso.o CC [M] /usr/local/src/git/linux/drivers/net/usb/lan78xx.o CC [M] /usr/local/src/git/linux/drivers/net/usb/asix_devices.o CC [M] /usr/local/src/git/linux/drivers/net/usb/asix_common.o CC [M] /usr/local/src/git/linux/drivers/net/usb/ax88172a.o LD [M] /usr/local/src/git/linux/drivers/net/usb/asix.o CC [M] /usr/local/src/git/linux/drivers/net/usb/ax88179_178a.o CC [M] /usr/local/src/git/linux/drivers/net/usb/cdc_ether.o CC [M] /usr/local/src/git/linux/drivers/net/usb/cdc_eem.o CC [M] /usr/local/src/git/linux/drivers/net/usb/dm9601.o CC [M] /usr/local/src/git/linux/drivers/net/usb/sr9700.o CC [M] /usr/local/src/git/linux/drivers/net/usb/sr9800.o CC [M] /usr/local/src/git/linux/drivers/net/usb/smsc75xx.o CC [M] /usr/local/src/git/linux/drivers/net/usb/smsc95xx.o CC [M] /usr/local/src/git/linux/drivers/net/usb/gl620a.o CC [M] /usr/local/src/git/linux/drivers/net/usb/net1080.o CC [M] /usr/local/src/git/linux/drivers/net/usb/plusb.o CC [M] /usr/local/src/git/linux/drivers/net/usb/rndis_host.o CC [M] /usr/local/src/git/linux/drivers/net/usb/cdc_subset.o CC [M] /usr/local/src/git/linux/drivers/net/usb/zaurus.o CC [M] /usr/local/src/git/linux/drivers/net/usb/mcs7830.o CC [M] /usr/local/src/git/linux/drivers/net/usb/usbnet.o CC [M] /usr/local/src/git/linux/drivers/net/usb/int51x1.o CC [M] /usr/local/src/git/linux/drivers/net/usb/cdc-phonet.o CC [M] /usr/local/src/git/linux/drivers/net/usb/kalmia.o CC [M] /usr/local/src/git/linux/drivers/net/usb/ipheth.o CC [M] /usr/local/src/git/linux/drivers/net/usb/sierra_net.o CC [M] /usr/local/src/git/linux/drivers/net/usb/cx82310_eth.o CC [M] /usr/local/src/git/linux/drivers/net/usb/cdc_ncm.o CC [M] /usr/local/src/git/linux/drivers/net/usb/huawei_cdc_ncm.o CC [M] /usr/local/src/git/linux/drivers/net/usb/lg-vl600.o CC [M] /usr/local/src/git/linux/drivers/net/usb/qmi_wwan.o CC [M] /usr/local/src/git/linux/drivers/net/usb/cdc_mbim.o CC [M] /usr/local/src/git/linux/drivers/net/usb/ch9200.o MODPOST 1 modules CC [M] /usr/local/src/git/linux/drivers/net/usb/qmi_wwan.mod.o LD [M] /usr/local/src/git/linux/drivers/net/usb/qmi_wwan.ko make: Leaving directory '/usr/src/linux-headers-5.7.0-1-amd64' Why is this? Am I doing something wrong here? This is quite annoying. Not only does it take much more time than necessary. It also causes the build to fail if any of the unnecessary source files fail to build. Which is expected with my use case, building unmodified drivers from a different kernel version. E.g trying to rebuild qmi_wwan from the current net/master repo on a Debian 5.6 kernel fails because r8152.c implement new ethtool_ops fields: bjorn@miraculix:/usr/local/src/git/linux$ make -C /lib/modules/5.6.0-2-amd64/build M=$(pwd)/drivers/net/usb clean make: Entering directory '/usr/src/linux-headers-5.6.0-2-amd64' CLEAN /usr/local/src/git/linux/drivers/net/usb/Module
Re: .config
Pratyush Das writes: >> >> Next time try make -j > > I thought it was limited by the number of processor threads? In this case, > if each CPU core has just one thread, the +1 does not really serve a > purpose? It's not limited. And the processes will compete for more than just CPU resources, so it can make sense to run a few more than you have CPU cores. This gives the scheduler something to work with when some of the make processes are blocking on IO. Personally I often use twice the number of cores, including the hyperthreaded ones. So I run 'make -j16' on a 4 core CPU with HT. You won't see much improvement by overcommitting like this, but it doesn't harm either. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] staging: rtl8192u: specify printk's KERN_ in ieee80211
Paulo Miguel Almeida writes:
> Checkpatch reports 'WARNING: printk() should include KERN_
> facility level'. Fix this by specifying a relevant KERN_ value
> for each line in which it was missing.
Although this is true, there are also additional best practice rules wrt
use of printk in drivers and debug level printks in particular.
Checkpatch does not tell you everything, unfortunately ;-)
You should always use dev_dbg() or netif_dbg() or similar macros instead
of printk in drivers. This way debug messages can be compiled away when
not needed, or even dynamically enabled/disabled on kernels built with
dynamic debugging. You should also drop stuff like __func__ since that
can be enabled dynamically as necessary with dev_dbg().
Take a look at
https://www.kernel.org/doc/html/v5.4/admin-guide/dynamic-debug-howto.html
and play it if you haven't already. This an extremely useful feature.
See some of the drivers in drivers/net/wireless for examples of how to
use dev_dbg().
> Signed-off-by: Paulo Miguel Almeida
> ---
> .../staging/rtl8192u/ieee80211/ieee80211_rx.c | 24 +--
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
> b/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
> index 00fea127bdc3..f38986d74005 100644
> --- a/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
> +++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
> @@ -810,11 +810,11 @@ static u8 parse_subframe(struct sk_buff *skb,
> nSubframe_Length = (nSubframe_Length >> 8) +
> (nSubframe_Length << 8);
>
> if (skb->len < (ETHERNET_HEADER_SIZE +
> nSubframe_Length)) {
> - printk("%s: A-MSDU parse error!!
> pRfd->nTotalSubframe : %d\n",\
> + printk(KERN_DEBUG "%s: A-MSDU parse error!!
> pRfd->nTotalSubframe : %d\n",
> __func__, rxb->nr_subframes);
> - printk("%s: A-MSDU parse error!! Subframe
> Length: %d\n", __func__, nSubframe_Length);
> - printk("nRemain_Length is %d and
> nSubframe_Length is : %d\n", skb->len, nSubframe_Length);
> - printk("The Packet SeqNum is %d\n", SeqNum);
> + printk(KERN_DEBUG "%s: A-MSDU parse error!!
> Subframe Length: %d\n", __func__, nSubframe_Length);
> + printk(KERN_DEBUG "nRemain_Length is %d and
> nSubframe_Length is : %d\n", skb->len, nSubframe_Length);
> + printk(KERN_DEBUG "The Packet SeqNum is %d\n",
> SeqNum);
> return 0;
> }
>
I see that this function, and many others in this driver, does not
access any device specific data. So you'll probably have to do
something about that. A bit more work required here than just setting
the printk level.
Hmm... I was going to suggest that you looked at the driver's TODO file
just to make sure that this work isn't futile e.g because it conflicts
with planned/suggested driver restructuring. But I see that the TODO
file is missing. Weird. I thought it was required for all staging
drivers. Learning something new every day...
Bjørn
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel TLS
"Valdis Klētnieks" writes: > On Sat, 30 Nov 2019 09:13:35 +0100, Bjrn Mork said: > >> include/linux/errno.h is kernel internal only. The UAPI header is >> uapi/linux/errno.h, which is an alias for uapi/asm/errno.h. There is no >> 524 in include/uapi/asm-generic/errno.h or >> include/uapi/asm-generic/errno-base.h >> >> The codes in include/linux/errno.h should be translated for userspace. >> This does look like a bug in the kernel tls code. > > Hmm... git grep ENOTSUPP has 1,516 hits. I haven't checked if it > gets translated in one place, or if it gets done in a kazillion places. Definitely more than one, but probably less than a kazillion. I believe the userspace wrappers usually translates errors from the lower levels to something conforming to the documented userspace API. My version of setsockopt(2) says RETURN VALUE On success, zero is returned for the standard options. On error, -1 is returned, and errno is set appropriately. Netfilter allows the programmer to define custom socket op‐ tions with associated handlers; for such options, the re‐ turn value on success is the value returned by the handler. ERRORS EBADF The argument sockfd is not a valid file descrip‐ tor. EFAULTThe address pointed to by optval is not in a valid part of the process address space. For getsockopt(), this error may also be returned if optlen is not in a valid part of the process ad‐ dress space. EINVALoptlen invalid in setsockopt(). In some cases this error can also occur for an invalid value in optval (e.g., for the IP_ADD_MEMBERSHIP option described in ip(7)). ENOPROTOOPT The option is unknown at the level indicated. ENOTSOCK The file descriptor sockfd does not refer to a socket. If you look at e.g. udp_lib_setsockopt() you'll see that it conforms strictly to this. I don't know why do_tcp_setsockopt() doesn't. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel TLS
"Valdis Klētnieks" writes: > On Fri, 29 Nov 2019 23:37:35 -0500, Jeffrey Walton said: > > repl: bad addresses: > Valentin VidiD -- no mailbox in > address, only a phrase (Valentin VidiD) >> On Fri, Nov 29, 2019 at 3:04 PM Jeffrey Walton wrote: >> > ... >> > So now I am at: >> > >> > $ gcc -Wall -g2 -O1 ktls.c -o ktls >> > $ ./ktls >> > setsockopt failed, 524, Unknown error 524 >> >> Now open in the Fedora bug tracker: >> https://bugzilla.redhat.com/show_bug.cgi?id=1778348 > > Looks like the 'unknown error' issue is a glibc strerror() problem. On the > kernel side, git blame says: > > [/usr/src/linux-next] git blame include/linux/errno.h | grep -C 5 524 > ^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 22) > ^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 23) /* Defined > for the NFSv3 protocol */ > ^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 24) #define > EBADHANDLE521 /* Illegal NFS file handle */ > ^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 25) #define > ENOTSYNC 522 /* Update synchronization mismatch */ > ^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 26) #define > EBADCOOKIE523 /* Cookie is stale */ > ^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 27) #define > ENOTSUPP 524 /* Operation is not supported */ > ^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 28) #define > ETOOSMALL 525 /* Buffer or request is too small */ > ^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 29) #define > ESERVERFAULT 526 /* An untranslatable error occurred */ > > So I'm mystified why glibc's strerror() doesn't handle it. > Though I think Alexander is correct on why the kernel returns ENOTSUPP. include/linux/errno.h is kernel internal only. The UAPI header is uapi/linux/errno.h, which is an alias for uapi/asm/errno.h. There is no 524 in include/uapi/asm-generic/errno.h or include/uapi/asm-generic/errno-base.h The codes in include/linux/errno.h should be translated for userspace. This does look like a bug in the kernel tls code. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Try/catch for modules?
Martin Galvan writes: > I'm writing a kernel module, and am trying to implement some > exception-handling mechanism so that the system won't oops/panic if my > module does e.g. a NULL dereference. Why don't you test your pointer for NULL instead? Sounds like a hell of a lot simpler solution to me. But I'm probably missing something as usual... Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: GPIO Driver for Skylake-Y PCH
"Alexander Ivanov" writes: > We have hundreds such units and I heard about plans to upgrade to 30 'soon'. Quite off-topic, but I just had to comment on such plans: Fedora is the wrong distro for you. You should be planning for RHEL instead. Or a similar stable distro. Fedora is a distro for those who don't need to plan the next upgrade, but just can (and will) do it whenever there is a new release. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: GPIO Driver for Skylake-Y PCH
"Alexander Ivanov" writes: > Device is indeed there: >> lspci -vvvnns 1f.1 >> 00:1f.1 Memory controller [0580]: Intel Corporation Device [8086:9d20] (rev >> 21) >> Subsystem: Gigabyte Technology Co., Ltd Device [1458:1000] >> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- >> Stepping- SERR- FastB2B- DisINTx- >> Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > SERR- > Latency: 0 >> Region 0: Memory at 7d00 (64-bit, non-prefetchable) [size=16M] >> >> >> ps. I misstyped device address in my original post, it is supposed to be >> function 1 not 2: d31:f1. > > gpio-pch depends on X86_32 || MIPS || COMPILE_TEST > > config GPIO_PCH > tristate "Intel EG20T PCH/LAPIS Semiconductor IOH(ML7223/ML7831) GPIO" > depends on X86_32 || MIPS || COMPILE_TEST > select GENERIC_IRQ_CHIP > > the platform at hand, is not X86_32 nor MIPS. It means gpi-pch requires > CONFIG_COMPILE_TEST (to compile drivers which wont load). Sure enough, > even when driver enumerates, it fails to map BAR: > > [ 105.965846] pci :00:1f.1: [8086:9d20] type 00 class 0x058000 > [ 105.965928] pci :00:1f.1: reg 0x10: [mem 0xfd00-0xfdff 64bit] > [ 105.967084] pci :00:1f.1: BAR 0: assigned [mem 0x7d00-0x7dff > 64bit] > [ 105.978037] pch_gpio :00:1f.1: pch_gpio_probe : pci_iomap FAILED > [ 105.978194] pch_gpio :00:1f.1: pch_gpio_probe Failed returns -12 > [ 105.978317] pch_gpio: probe of :00:1f.1 failed with error -12 This seems to be from an older kernel, but anyway: pch_gpio_probe() attempts to map BAR 1. Your device does not have any such resource. So it fails. > Any suggestions on what driver (if any available) should be used instead? I wouldn't know. But I believe your device looks too different to be compatible with whatever devices this driver was made for. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: GPIO Driver for Skylake-Y PCH
"Valdis Klētnieks" writes: > Though I'm having a hard time aligning that with "D31:F2". Are you confusing > a PCI address with a PCI ID, or is this on a non-PCI bus? "D31:F2" is device 31, function 2. We're used to see this as "1f.2". The question is really: Is there such a device in the system? And if so: What's the ID? That's easy to find out: lspci -vvvnns 0:1f.2 Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: writes to /dev/kmsg
Lev Olshvang writes: > Kernel documentation describes interface > https://www.kernel.org/doc/Documentation/ABI/testing/dev-kmsg > > I wonder what kind of applications use it? > Why somebody need to use kmsg instead of syslog? > > Can anybody give example of such application? Can't answer your first two good questions. But here is a well known example application: https://github.com/systemd/systemd/blob/master/src/basic/log.c#L109 Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: a Linux device driver
Abu Rasheda writes: > wondering which hardware is missing a driver, I can try yo buy/acquire the > hardware No need to buy any hardware. Just look around you and see what you already have. If you don't see anything you want to write a driver for, then maybe you shouldn't. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Security updates of Linux kernel
Greg KH writes: > For a full description on this whole thing, please see this post where I > describe how the kernel developers treat "security" bugs, and how to > ensure you are running a secure system: > http://www.kroah.com/log/blog/2018/02/05/linux-kernel-release-model/ "At the current kernel release rate, the number will change to 5.x sometime in 2018." That's bold. Could cost you some very exclusive whisky if I understand the version numbering process correctly. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Interface between LTE devices and Linux
Jeffrey Walton writes: > In addition to GKH's answer, what I have seen... > > Some Android code to talk to the radio is written in plain java, like > https://chromium.googlesource.com/android_tools/+/18728e9dd5dd66d4f5edf1b792e77e2b544a1cb0/sdk/sources/android-19/com/android/internal/telephony/CommandsInterface.java . Well, that only talks to the RIL so it is pretty high up the stack. If you want the software that actually implement the 3GPP stuff, then you'd either give Qualcomm your right arm and your first born or you look at what the Osmocom guys are doing. The RIL is closed source too, and it will only use some high level protocol like QMI or AT commands to send requests to the modem firmware anyway. You can skip both the java code and the closed source RIL and go straight for oFono or ModeManager if you want stuff at that layer. But I understood the original request as wanting to see more detail at the actual radio layer. That's difficult. But you might get some useful info out of the debug interfaces. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Load partially USB composite device
loïc tourlonias writes: > On Wed, Aug 9, 2017 at 9:25 AM, Bjørn Mork wrote: > >> Sounds like your system has other issues, but whatever... > > I may not have been clear in my explanation. What seems wrong with my system? "ethXX which interferes with a service". It should not. >> The cdc_ether driver treats any ID entry with .driver_info = 0 as a >> blacklist entry. So you can dynamically blacklist devices by writing >> the "VID PID" to /sys/bus/usb/drivers/cdc_ether/new_id before the device >> is probed. >> > I have tried this and look at the source code of > driver/usb/core/driver.c. But I think this is not what I required. > What I understand is that the new_id file is used to dynamically add > new USB id to the cdc_ether driver. True. But as I said: The cdc_ether driver use the device ID list for blacklisting. This is an implementation detail specific to this driver. It will use the .driver_info field as a pointer to usbnet specific data. But if the field is 0, then the entry becomes a blacklist entry instead. Dynamically added entries have all fields set to 0 by default, and will also be tried before the built-in entries (since v3.15). So adding a dynamic entry to the cdc_ether driver means adding a blacklist entry (Unless you explicitly reference an existing entry for inheritance). Try it. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Load partially USB composite device
loïc tourlonias writes: > Hi everybody, > > In my project I have an USB composite device (a LTE modem) which use > USB to communicate with the processor. This device has several > interface to communicate but I do not use all of them. In particular, > it loads cdc_ether device which I don't use and I have an undesired > ethXX which interferes with a service in my system. Sounds like your system has other issues, but whatever... > To schematize, let's say my device is loaded on port 2 of usb1, I have > the following USB topology: > - 1-2:1.0: tty > - 1-2:1.1: tty > - 1-2:1.2: tty > - 1-2:1.3: tty > - 1-2:1.4: tty > - 1-2:1.5: eth (not desired) > > Is there a way to prevent this specific ethXX to mount? > > I've already tried to create a udev rules, but I don't manage to stop > the loading process. > Here is a summary of my tries: > 1/ I couldn't use the /sys/bus/usb1/.../1-2/activated file in my udev > rule because it's an USB composite device and I want to use the tty > interfaces but not the eth interface > > 2/ I have tried to stop the udev loading process, but setting MODALIAS > environment variable to a NULL-string doesn(t do the trick and > last-rule udev option has been removed in my udev version (1.8.2). > > 3/ I have tried to create a custom environment variable IGNORE_ETH and > modify my last rule which run modprobe with the modalias variable. In > the logs I see that modprobe isn't called by udev rules, but the > cdc_ether device is loaded all the same. > > 4/ I have think of creating a stub cdc_ether driver and use the > /etc/modprobe.d/my_file.conf to preempt the loading for my specific > usb composite device but this solution is ugly and I'm not sure it > will work. The cdc_ether driver treats any ID entry with .driver_info = 0 as a blacklist entry. So you can dynamically blacklist devices by writing the "VID PID" to /sys/bus/usb/drivers/cdc_ether/new_id before the device is probed. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: minimum commit id length when fixing a patch
Kevin Wilson writes: >>Personally I prefer having the full id in the "normal" git log > May I ask, out of interest, why ? according to my understanding, the > 12 digits ID should show a unique patch (at least for kernel git > trees, which is primarily where I use it) Because I'm used to having the full id in the log, I guess. And it takes up a line anyway, so there is nothing to save. And I rarely/never copy the id from a full log. If I want to refer to the id, then I use some formatting macro for that. Like the --pretty=fixes from the config example, But this is all subjective. Whatever works for you is fine :-) Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: minimum commit id length when fixing a patch
Kevin Wilson writes: > Thanks, Bjorn. > > I added in /root/.gitconfig > ... > [core] > abbrev = 12 > [pretty] > fixes = Fixes: %h (\"%s\") > ... > > Still, "git log" shows more than 12 digits, like: > commit 0a528ee9a52007984fa60b0c4ef1f39fdf5edf8d > Author: Tariq Toukan > Date: Wed Jun 7 16:26:15 2017 +0300 > > IB/mlx4: Bump driver version > > Does it work for you ? See the section on "Commit Formatting" in git-log(1). The config only changes the abbreviated id, while the default log format use the full id. You can do "git log --abbrev-commit", or set "log.abbrevCommit" to change this default. Personally I prefer having the full id in the "normal" git log, but like to use the abbreviated id in fixes tags and other one-line references to commits. This is done by using %h instead of %H in the format specifier. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: minimum commit id length when fixing a patch
Kevin Wilson writes: > Hi, > I want to send a patch to LKML fixing something wrong which was caused > by other patch. > > Form what I understand, it is a good practice to mention the commit > title and the commit ID. > > A commit ID is very long. My question is: when mentioning in my commit > log the patch that caused the problem, what is the minimum commit id > length which I should use when presenting the patch that caused the > problem ? is such commit length is documented anywhere ? 12 It's mentioned here and there. One place is the .git/config example in section "2) Describe your changes" in Documentation/process/submitting-patches.rst : The following ``git config`` settings can be used to add a pretty format for outputting the above style in the ``git log`` or ``git show`` commands:: [core] abbrev = 12 [pretty] fixes = Fixes: %h (\"%s\") (BTW, using the "Fixes" tag might be appropriate for your patch) Or see for example: https://public-inbox.org/git/ca+55afy0_pwtfoys1tmnxipw9zkrncqhmoyyego00pjmizq...@mail.gmail.com/ Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Importance of kobject
Madhu K writes: > I am kernel newbie, I want to know the importance of kobject, can anybody > explain the importance of kobject with an example. I think the best generic example is that you can write Linux drivers, using kobjects all over, without ever having to actually worry about kobjects. You just use struct device, often without even realizing that there is a kobject embedded in it. At least that's all I know about them :-) If you want code exaples, then "git grep kobj drivers/" will provide enough for a lifetime. And more. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: endian patches
"Tobin C. Harding" writes: > Should [drivers/staging/*] patches to endian code be tested on hardware > before submission? All patches should be tested before submission, IF possible. But there is no reason to hold back a patch just because you cannot test it yourself. Submit it anyway, noting the level of testing you have done. E.g. "build-tested only", or "verified on LE but not tested on BE", or whatever you find appropriate. It is not uncommon for the author/submitter to be unable to test bug fixes on real hardware. Many endian fixes will be obvious enough to make testing unnessary. And even if the maintainer thinks testing is necessary, there might be reviewers with the necessary hardware but without the time or insight to write the code. I don't think there ever is a reason not to post a patch. Just make sure that you have done as much as you can to verify it yourself, and describe what you have done. Make it clear if you think it needs more testing, and why you haven't done that. Missing hardware is a very good reason. > During recent development of ks7010 driver, and from watching patch > review on de...@linuxdriverproject.org, I formed the opinion that > patches fixing endian issues need to be tested on hardware before they > can be *guaranteed* to be correct. No patch is *guaranteed* to be correct in my experience :) Seriously, I don't think there is anything special about endian fixes. Yes, they do add an additional hardware dimension, which often will trigger the missing test hardware problem. But the question about whether testing on hardware is necessary or not is the same as for all other fixes. So is the answer: It depends. Endian fixes like documenting the hardware registers, and adding conversion to and from the CPU endianness when accessing them, will often be obvious enough to be applicable even without testing. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: DWM 157 D1 Dongle support
Narasimha M writes: > Hi All, > > I am trying to support DMW 157 D1 dongle. I have the pid (7600) and > vids (2001) for this dongle. Could someone share the messagecontent > for usb_modeswitch to convert into modem. Thanks in advance. eject will usually switch D-Link dongles. But this modem is supported in the current usb-modeswitch-data. If it doesn't work for you, then please make sure you use the latest version. If it still doesn't work, then you will get better help at http://www.draisberghof.de/usb_modeswitch/bb/index.php Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: What is the fastest way to build and boot a kernel
Joe Smith writes: > In cases where IP rights are an issue Very few maintainers are lawyers. They cannot make that assertion. The administrative rules are simple, both for submitters and maintainers. They have to be. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: What is the fastest way to build and boot a kernel
Joe Smith writes: > On Thu, Apr 20, 2017 at 9:31 AM, Alexander Kapshuk > wrote: > >> then you just add a line saying:: >> >> Signed-off-by: Random J Developer >> >> using your real name (sorry, no pseudonyms or anonymous contributions.) > > How does anyone know what my real name is. No one does. It's up to you to make sure your name is real :) An example of what might otherwise happen: https://lwn.net/Articles/194729/ Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: pr_debug
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(&func->dev, "SDIO: Enabling device...\n");
?
Bjørn
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Merging device drivers to LK tree
valdis.kletni...@vt.edu writes: > On Tue, 14 Mar 2017 22:54:37 +0300, alexhoppus said: > >> No, I just try to understand the process. I don't fully understand what >> is the role of independent developer in the process of submitting new >> drivers to LK. What I mean is - hardware device vendors always ship >> device driver with their products. In this case several options are >> available: >> 1.) HW vendor ships only closed-source drivers and is not interested to >> open source this work. >> 2.) HW vendor publishes device drivers to the community by himself >> 3.) HW vendor put the device driver sources to their website ready for >> downloading and building, but make no effort for integrating them to LK. > > You missed one: > > 4.) HW vendor only ships a Windows or OSX client. And another one: 5.) vendor independent class drivers IMHO perfect for the independent developer since there will be documentation available. The USB class specs are freely available for example. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Understanding get_maintainer.pl and MAINTAINERS
Bjørn Mork writes: > The N entries are regex patterns. "bcm281*" matches any name starting > with "bcm28", followed by 0 or more 1's. This isn't entirely correct. I assumed there was some implicit anchoring on path name components, but there isnt. So "bcm281*" will match any file containing "bcm28" somewhere in the path. I am obviously not the first one making that bogus assumption. Very few of the "N:" entries in MAINTAINERS are anchored in any way. The rest of them are likely buggy. No one expects these strings to match in the middle of arbitrary path names. Even the example is a bit too wild IMHO: N: Files and directories with regex patterns. N: [^a-z]tegra all files whose path contains the word tegra The '[^a-z]' prevents this from matching any word containing "tegra". But it will still match e.g "INtegrator" or "b1tegrasp", which is unexpected. It would be better to use a more explicit anchor, like '[-/]tegra'. Or maybe even "/tegra". Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Understanding get_maintainer.pl and MAINTAINERS
Robin Krahl writes: > Hi again, > > I’m now preparing my patchset for bcm2835-audio. get_maintainer.pl > returns: > > $ ./scripts/get_maintainer.pl --nokeywords --nogit --nogit-fallback > drivers/staging/vc04_services/bcm2835-audio/ > Stephen Warren (maintainer:BROADCOM BCM2835 ARM > ARCHITECTURE) > Lee Jones (maintainer:BROADCOM BCM2835 ARM > ARCHITECTURE) > Eric Anholt (maintainer:BROADCOM BCM2835 ARM > ARCHITECTURE) > Greg Kroah-Hartman (supporter:STAGING > SUBSYSTEM) > Florian Fainelli (maintainer:BROADCOM > BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...) > Ray Jui (maintainer:BROADCOM > BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...) > Scott Branden (maintainer:BROADCOM > BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...) > bcm-kernel-feedback-l...@broadcom.com (maintainer:BROADCOM > BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...) > linux-rpi-ker...@lists.infradead.org (moderated list:BROADCOM BCM2835 > ARM ARCHITECTURE) > linux-arm-ker...@lists.infradead.org (moderated list:BROADCOM BCM2835 > ARM ARCHITECTURE) > de...@driverdev.osuosl.org (open list:STAGING SUBSYSTEM) > linux-ker...@vger.kernel.org (open list) > > Why are the BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE guys added > to the list? The MAINTAINERS file defines these rules: > > BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITECTURE > M: Florian Fainelli > M: Ray Jui > M: Scott Branden > M: bcm-kernel-feedback-l...@broadcom.com > T: git git://github.com/broadcom/mach-bcm > S: Maintained > N: bcm281* > N: bcm113* > N: bcm216* > N: kona > F: arch/arm/mach-bcm/ > > As far as I see, none of these rules matches the given path. Am I > missing something? The N entries are regex patterns. "bcm281*" matches any name starting with "bcm28", followed by 0 or more 1's. So "bcm2835-audio" matches. Yes, that looks like a bug in the MAINTAINERS entry. They probably intended something along N: bcm281.* N: bcm113.* N: bcm216.* Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH 0/7] security: apparmor: apparmorfs.c Checkpatch mods
Greg KH writes: > On Sat, Nov 26, 2016 at 01:02:14PM -0500, Walt Feasel wrote: > >> So kernelnewbies is not to be used to learn about how to fix >> checkpatch type warning? > > Maybe, but really, if you have a well-formed patch, just send it to the > correct maintainers, it's up to them to accept it or not, that's their > job :) And I think the most important reason for doing that is because only they can answer the questions. You need to know what the code does to be able to answer things like "is it OK to replace BUG_ON with WARN_ON here?". Although that is preferable according to checkpatch, it's not necessarily a 1-to-1 replacement. The error path changes, and the existing code is likely not tested or developed with the new path in mind. Nobody(?) in kernelnewbies knows anything about the apparmor code. It's not that we don't want to answer. We just can't. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: MODULE_DEVICE_TABLE type=of means?
Muni Sekhar writes: > I see that following dma engine driver uses MODULE_DEVICE_TABLE with > ‘type=of’. > What does ‘type=of’ means? How to trigger this driver’s probe and > remove to be called? "Open Firmware", aka "Device Tree". See Documentation/devicetree/ Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How to disable building of -dbg Debian package?
Aleksander Alekseev writes: > Hello. > > I'm building Linux kernel like this: > > ``` > cp /boot/config-$(uname -r) ./.config > make olddefconfig > make -j4 deb-pkg LOCALVERSION=-custom > ``` > > Resulting files are (for 4.7.0 kernel): > > ``` >966694 linux-firmware-image-4.7.0-custom_4.7.0-custom-1_amd64.deb > 10316460 linux-headers-4.7.0-custom_4.7.0-custom-1_amd64.deb > 45639036 linux-image-4.7.0-custom_4.7.0-custom-1_amd64.deb > 471400164 linux-image-4.7.0-custom-dbg_4.7.0-custom-1_amd64.deb >851664 linux-libc-dev_4.7.0-custom-1_amd64.deb > ``` Maybe the relatively new "bindeb-pkg" target is closer to what you want? See "make help" for all alternatives. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] INITEST: Documentation: Explains how INITEST works.
Amit Kumar writes: > Signed-off-by: Amit Kumar > > This is a test patch. > Is this patch in right format? > --- > Documentation/initest.txt | 7 +++ > 1 file changed, 7 insertions(+) > create mode 100644 Documentation/initest.txt > > diff --git a/Documentation/initest.txt b/Documentation/initest.txt > new file mode 100644 > index 000..eed4124 > --- /dev/null > +++ b/Documentation/initest.txt > @@ -0,0 +1,7 @@ > +INITEST > + > +1) This is the same user space program /sbin/init, but for the purpose of > testing kernel system calls. > + > +2) It will also use testing drivers to test internal kernel API. > + > +3) This is a test patch. Looks pretty good. But a few more things to keep in mind: 1) There should be *some* body text describing the patch, even for a very basic change which is explained in full in subject. This goes first in the body, separated from the tags with a single empty line. 2) Signed-off-by and other tags go at the end of the body, right before the "---" separator. Don't put anything between the SOB and the separator. I realize that this was just a question that you wouldn't make part of the submitted patch but still: It broke your example... 3) There is a place for questions about the patch which you do not want to be part of the commit message: Right After the first "---" separator. Anything yout put there will be ignored by git when the patch is applied, just like the diffstat git includes by itself. This is useful if you need to explain something to the maintainer regarding how to apply the patch, or if ytou have questions about it which are irrelevant if applied. So the end result would be: Subject: [PATCH] INITEST: Documentation: Explains how INITEST works. This is a test patch. Signed-off-by: Amit Kumar --- Is this patch in right format? Documentation/initest.txt | 7 +++ 1 file changed, 7 insertions(+) create mode 100644 Documentation/initest.txt diff --git a/Documentation/initest.txt b/Documentation/initest.txt [etc] Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Device Driver problem
Gurpartap Singh writes:
> I am using Quectel gsm module on Arm board from olimex. While attaching the
> Device via USB, dmesg shows following:
>
> *qmi_wwan 2-1:1.0: not on our whitelist - ignored*
>
> *what does it mean?*
We can definitely agree that this was not an informative or good
message. Luckily it was removed from the driver with commit
03304bcb5ec4 ("net: qmi_wwan: use fixed interface number matching") more
than 4 years ago...
It would help if you said which kernel version you were using when
asking about such things, especially when the kernel is as ancient as
this. That message only ever appeared in v3.4 and v3.5, and was mostly
useless noise. The driver had a per-device whitelist of supported
interface numbers before we got interface number matching in the USB
core. For some reason, I thought it was a good idea to inform about the
non-matching interfaces. Don't know why. Probably too little thought
involved in the process.
The current meaning of the message is that you are using an too old
version of the kernel/driver :)
Bjørn
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Proper way to get device file minor number from struct file
"Matwey V. Kornilov" writes: > Hello, > > I am looking through some legacy out of tree custom linux kernel device > driver. > > It is full of lines like the following: > > iminor(fp->f_dentry->d_inode) > > here struct file *fp is an argument of callback of struct file_operations. > > Documentation/filesystems/porting says: > > "f_dentry is gone; use f_path.dentry, or, better yet, see if you can > avoid it entirely" > > So, is there a proper compatible way to do the same? Don't know how proper it is, but a "git grep iminor drivers/" shows that minor = iminor(file_inode(file)); is a very common construct. Or alternatively, do the iminor(inode) lookup once in open() to lookup up your device struct or whatever, and then save that reference in file->private_data, thereby avoiding the need to know the minor anywhere else. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Identifying whether a pci device is x1, x4, x8 or x16
Kevin Wilson writes: > Is there a way that "lspci -vvvnn" will return only info about a given > bdf (like :02:00.0, which is what ethtool -i eth4 returns > in the "bus-info" field. lspci -vvvnns :02:00.0 "man lspci" is your friend :) Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Identifying whether a pci device is x1, x4, x8 or x16
Kevin Wilson writes: > Hi all, > Is there a way to find out whether a PCI device in a given Linux > machine is x1, x4, x8 or x16, in terms > of physical dimensions (without opening the box...) Sure. Use something like "lspci -vvvnn" and check out LnkCap and LnkSta under Capabilities. There you can see both the number of channels and symbol rate. For example for an x8 card in an x4 slot (connection-wise - the connector is of course wider or the x8 card wouldn't fit): LnkCap: Port #0, Speed 5GT/s, Width x8, ASPM L0s, Exit Latency L0s <512ns, L1 <4us LnkSta: Speed 2.5GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: udev & modalias files
Muni Sekhar writes: > I see lot of modalias files under /sys directory. > > For e.g: > > # cat /sys/devices/pci:00/:00:1c.0/:02:00.0/modalias > > pci:v1556dsv4000sdbc08sc05i01 > > > > I would like to know which part of the kernel module creates sysfs > modalias file? lots of different places. Do a "git grep modalias drivers/" to see many of them. That particular file is created by drivers/pci/pci-sysfs.c Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: exporting kernel headers via the include/uapi directory
"Robert P. J. Day" writes: > while i'm here, some pedantry ... what is the point of adding a > header file somewhere under include/uapi/ without > *immediately* adding it to the Kbuild file so that it's exported? I don't know the answer to that. But having done this once, I can answer why *I* did it: Ignorance. I didn't realize that I had to update the Kbuild file, but wrongly assumed that creating a file somewhere in include/uapi was enough. Maybe that's the reason for most of these errors? Some automatic check, or maybe even automatic fix, would be nice. Should be pretty easy to do. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: USB device debugging
Narasimha M writes: > Thanks for clear explanation. Could you please let me know where does > host_controller will be present is it in USB device or USB core part > of kernel. > > Actually my issue is that we ported Gobinet driver from open source to > support one dongle. After porting, it is working fine on little endian > host (linux-2.6.31 kernel). We have added some changes in driver code > o support it for big endian hosts. After adding the changes with the > help of le16_to_cpu () function dongle is working in one of our big > endian hosts (which has linux-3.10.20), but facing corrupted packet > issue in other bigendian supported host (linux-2.6.32). Could you > please help in providing some pointers here Sounds like you have a bug in your code. Did you expect me to make a more precise guess? Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: USB device debugging
Narasimha M writes: > Thanks for the info. Sorry to ask you again, where does the usb driver > (GobiNet in my case) comes into picture in receive packet flow. I > suspect that the driver has to send some data (may be with some > interrupts) to rx_complete and then it will go to rx_submit. Is my > understanding is correct ? or if rx_submit is the first function to > generate the data, then where does Gobinet driver comes into place. > Could you please explain. I don't know how some usb driver works. This > is the first time i am working on it. GobiNet isn't part of the receive packet flow at all, if we assume a non-buggy Gobi device operating in 802.3 mode. The rx_fixup callback is called, but it does nothing. There isn't anything to do. The buffer is filled with an ethernet packet by the device + host controller. The usbnet_bh() tasklet is responsible for calling rx_submit (indirectly in newer kernels). This is triggered by setting the EVENT_DEV_OPEN flag, which is done by usbnet_open(). GobiNet obfuscates this quite a bit, but it doen't do anything extra-ordinary here - it simply calls usbnet_open() when you open the netdev. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: USB device debugging
Narasimha M writes: > I am able to see the corrupted data in rx_complete itself. Then the only likely source is the device. In theory it could be the host controller, but that is very unliekely unless you use some out-of-tree driver there too. You can easily verify that usbnet can be ruled out by follwing the earlier usbmon advice. > What are > the possibilities for the data corruption in rx_complete. Any fixes to > resolve this. And from where the data in rx_submit generates rx_submit allocates new buffers using __netdev_alloc_skb_ip_align() like many other network drivers. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: USB device debugging
Narasimha M writes: > Thanks for explanation. Here data is getting corrupted before it comes > to the usbnet itself, so after it reaches to usbnet and go through > network stack, it is failing in tcp checksum and packet is getting > dropped. Same driver is working with linux-3.10.20 but not working > with linux-2.6.32.Not able to find the exact function in driver which > sends receive packet to usbnet, not able to proceed further. Please > suggest some pointers to proceed further. This is no surprise. There is no "send receive packet to usbnet". usbnet allocates a receive buffer and hands it to the USB host controller. This happens in rx_submit(). The host controller calls the rx_complete() callback when it gets data from the device. This callback will trigger further handling in the usbnet_bh() tasklet, calling rx_process(). This again calls the minidriver specific rx_fixup() callback if there is any, which is GobiNet's only chance of inspecting and possibly modifying the buffer. But normally it will not touch the buffer, since there is no fixup necessary for Gobi devices in 802.3 mode (they transmit plain ethernet packets). rx_process() ends up calling usbnet_skb_return() which hands the buffer over the the networking stack using netif_rx(). So, if we ignore the possible firmware bug workarounds in rx_fixup(), then nothing ever touches the receive buffer in usbnet. It's just a handle being passed around. Note that I don't remember, or care, what 2.6.32 might have done. It's too outdated to be relevant. But the usbnet design is much older and haven't changed drastically, so I assume most of the above is valid there too. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: USB device debugging
Greg KH writes: > On Tue, May 24, 2016 at 01:48:16PM +0530, Narasimha M wrote: >> Thanks for the information. But i want to know the flow of receive >> packet from usb driver to linux stack. I am facing an issue that >> corrupted data is coming to usbnet_bh function. So i want to know >> about the place where we generate the data in usb driver and sent it >> to usbnet. Could you please help in finding out this. I am using >> Gobinet driver as usb driver. > > Look in the usbnet driver itself, it is the one that receives the data > from the USB core. > > If you suspect the USB core isn't getting the data properly, use usbmon > to look at the "raw" USB data for the device, instructions for how to > use that is in the kernel documentation directory. I would have started with usbmon in this case. Some Gobi firmwares are known to corrupt ethernet headers in various ways, if that is the problem. There are numerous workarounds for these issues in the qmi_wwan driver, and AFAIK also in the GobiNet driver. But the worst mess is unfixable, where the header is overwritten by arbitrary data and you don't even know if there is a header there or not. The only possible workaround for those devices is using "raw-ip" mode, where you can be certain that there is no ethernet header (and therefore no mess) Nothing can be ruled out of course, but I say that there is little chance of any data corruption in the usbnet code. It doesn't really touch the packet buffers between USB controller and network stack. The corruption is most likely to happen in firmware, or possibly in GobiNet although I haven't yet seen any proof of that. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: what is the rationale for all ethernet device vendors being "default y"?
"Robert P. J. Day" writes: > just noticed that on my x86 system, when i do a: > > $ make defconfig > > under "Ethernet driver support", all the top-level vendor choices > (3com, adaptec and so on) all have Kconfig entries with: > > default y > > reasonably, for each vendor, all of their cards are not "default y" > (that would be kind of silly), but what is the logic behind making > each vendor selection "default y"? To avoid introducing build regressions with the introduction of these directories: http://lists.openwall.net/netdev/2011/08/23/41 This is because these directories were retro-fitted to the Kbuild system for most ethernet drivers. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Contributing to Kernel Networking stack
Shraddha kamat writes: > I have strong desire to contribute to kernel networking stack. What is the > most effective way to do some pretty significant changes (bug fixes, > feature addition) in less time. By providing high quality patches which improve Linux and require minimal maintainer efforts to apply. It's as simple as that :) A few key words: test, explain, listen I'd also suggest starting simple, sending tested bug fixes obviously improving the code. Significant improvements, like e.g. adding features, might be difficult to start with. It's good to be known for quality work first. And there will always be a question on how to implement more complex changes. You should expect several rounds back to the drawing board for each such patch set. Having some experience and "gut feeling" will reduce the number. Which is necessary, since you might otherwise end up with noone bothering to review after a few cycles. That puts all the load on the maintainer. Which is not good. But if you have something to offer and the ability to take feedback, then anything is possible. Yes, and of course: READ the available docs in Documentation/Submit* Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: variant length array?
"Robert P. J. Day" writes:
> On Tue, 5 Apr 2016, Wenda Ni wrote:
>
>> Hi all,
>>
>> I come across the following code in a kernel module code. It defines
>> an array whose length is variant at runtime, depending on the actual
>> inputs. It seems that kernel compiler supports this, which is
>> obvious an error in the standard ANSI C. Do I have the correct
>> understanding on it?
>>
>> Thank you.
>>
>>
>> u32 rxe_icrc_hdr(struct rxe_pkt_info *pkt, struct sk_buff *skb)
>> {
>> ...
>> int hdr_size = sizeof(struct udphdr) +
>> (skb->protocol == htons(ETH_P_IP) ?
>> sizeof(struct iphdr) : sizeof(struct ipv6hdr));
>> u8 tmp[hdr_size + RXE_BTH_BYTES];
>> ...
>> }
>
> pretty sure "sizeof" can be calculated at compile time so i don't
> see a problem here.
Yes, but skb->protocol is variable and sizeof(struct iphdr) !=
sizeof(struct ipv6hdr)). Is the compiler smart enough to just use the
largest possible value? The logic here is pretty similar to a union,
which it of course wouldn't have any problems calculating the size of.
Bjørn
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Finding when a chip was supported in the kernel
Rob Groner writes: > Hmm...I don't think I share the idea that it was extremely easy. :) OK :) > But it is something I can try at least, assuming I can get at least as > far as figuring out which driver file a particular chip gets its > support from. With Intel chips, that IS pretty easy. > > Using the blame I see that it gives a date and a commit reference. > How do I then correlate that to the kernel version where it first > showed up? I'm assuming there's a git command for showing that. That was the other command Carlo gave, which I failed to quote. Sorry about that. Carlo wrote: > git describe --contains $SHA e.g bjorn@nemi:/usr/local/src/git/linux$ git describe --contains 4662e82b2cb41 v2.6.28-rc1~717^2~323 Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Finding when a chip was supported in the kernel
Carlo Caione writes: > On Mon, Feb 15, 2016 at 3:44 PM, Rob Groner wrote: >> >> >> Is there some specific place/way I can find the specific kernel version when >> support for an arbitrary chip was added? An example is the Intel 82574 >> Ethernet chip. I’m finding that google is failing me for finding the >> specific kernel of inclusion. This comes up somewhat often here at work >> (having to determine how far back our Linux support goes), so I’m trying to >> find the best way to determine this. > > git log --reverse $driver I often find it easier to use git blame for such stuff, looking at the dates of code related to the chip/feature in question. At least in cases like this where a single driver supports a number of different chips. You'll have to verify the results with "git show" of course, in case everything was refactored. The 82574 is a good example (since the authors made it easy with that comment): 1st attempt returns a code refactoring commit: bjorn@nemi:/usr/local/src/git/linux$ git log --reverse drivers/net/ethernet/intel/e1000e/82571.c commit dee1ad47f2ee75f5146d83ca757c1b7861c34c3b Author: Jeff Kirsher Date: Thu Apr 7 07:42:33 2011 -0700 intel: Move the Intel wired LAN drivers Moves the Intel wired LAN drivers into drivers/net/ethernet/intel/ and the necessary Kconfig and Makefile changes. Signed-off-by: Jeff Kirsher 2nd attempt returns the commit adding the driver, but that specific chip wasn't supported (a fact which might not be easy to sport using this method): bjorn@nemi:/usr/local/src/git/linux$ git log --reverse dee1ad47f2ee^ -- drivers/net/e1000e/82571.c commit bc7f75fa97884d41efbfde1397b621fefb2550b4 Author: Auke Kok Date: Mon Sep 17 12:30:59 2007 -0700 [E1000E]: New pci-express e1000 driver (currently for ICH9 devices only) This driver implements support for the ICH9 on-board LAN ethernet device. The device is similar to ICH8. The driver encompasses code to support 82571/2/3, es2lan and ICH8 devices as well, but those device IDs are disabled and will be "lifted" from the e1000 driver over one at a time once this driver receives some more live time. So you still don't know when the 82574 support was added git blame on the other hand, gives you this immediately: bjorn@nemi:/usr/local/src/git/linux$ git blame drivers/net/ethernet/intel/e1000e/82571.c e78b80b1079e1 drivers/net/ethernet/intel/e1000e/82571.c (David Ertman 2014-02-04 01:56:06 +1) /* Intel PRO/1000 Linux driver [..] bc7f75fa97884 drivers/net/e1000e/82571.c(Auke Kok 2007-09-17 12:30:59 -0700 21) e921eb1ac411a drivers/net/ethernet/intel/e1000e/82571.c (Bruce Allan 2012-11-28 09:28:37 + 22) /* 82571EB Gigabit Ethernet Controller 1605927fcee41 drivers/net/e1000e/82571.c(Bruce Allan 2008-11-21 16:51:06 -0800 23) * 82571EB Gigabit Ethernet Controller (Copper) bc7f75fa97884 drivers/net/e1000e/82571.c(Auke Kok 2007-09-17 12:30:59 -0700 24) * 82571EB Gigabit Ethernet Controller (Fiber) ad68076e07fa0 drivers/net/e1000e/82571.c(Bruce Allan 2008-03-28 09:15:03 -0700 25) * 82571EB Dual Port Gigabit Mezzanine Adapter ad68076e07fa0 drivers/net/e1000e/82571.c(Bruce Allan 2008-03-28 09:15:03 -0700 26) * 82571EB Quad Port Gigabit Mezzanine Adapter ad68076e07fa0 drivers/net/e1000e/82571.c(Bruce Allan 2008-03-28 09:15:03 -0700 27) * 82571PT Gigabit PT Quad Port Server ExpressMo bc7f75fa97884 drivers/net/e1000e/82571.c(Auke Kok 2007-09-17 12:30:59 -0700 28) * 82572EI Gigabit Ethernet Controller (Copper) bc7f75fa97884 drivers/net/e1000e/82571.c(Auke Kok 2007-09-17 12:30:59 -0700 29) * 82572EI Gigabit Ethernet Controller (Fiber) bc7f75fa97884 drivers/net/e1000e/82571.c(Auke Kok 2007-09-17 12:30:59 -0700 30) * 82572EI Gigabit Ethernet Controller bc7f75fa97884 drivers/net/e1000e/82571.c(Auke Kok 2007-09-17 12:30:59 -0700 31) * 82573V Gigabit Ethernet Controller (Copper) bc7f75fa97884 drivers/net/e1000e/82571.c(Auke Kok 2007-09-17 12:30:59 -0700 32) * 82573E Gigabit Ethernet Controller (Copper) bc7f75fa97884 drivers/net/e1000e/82571.c(Auke Kok 2007-09-17 12:30:59 -0700 33) * 82573L Gigabit Ethernet Controller 4662e82b2cb41 drivers/net/e1000e/82571.c(Bruce Allan 2008-08-26 18:37:06 -0700 34) * 82574L Gigabit Network Connection 8c81c9c315b7e drivers/net/e1000e/82571.c(Alexander Duyck 2009-03-19 01:12:27 + 35) * 82583V Gigabit Network Connection bc7f75fa97884 drivers/net/e1000e/82571.c(Auke Kok 2007-09-17 12:30:59 -0700 36) */ bc7f75fa97884 drivers/net/e1000e/82571.c(Auke Kok 20
Re: mkinitcpio
Tobin Harding writes: > Issue resolved thank you. I forgot to CC the list. Thanks also to Pablo > G. Gallardo. Please give a summary of how the issue was resolved, even if it may seem obvious to you now. The problem was important enough for you to ask about, and you can be sure that you are not alone. The next person having the same problem will find your question. A nice gesture would be to let them find your answer as well... Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How does the probe function gets called on a PCI device driver?
Henrique Montenegro writes:
> Hello list,
>
> I am reading through the e1000 driver and trying to figure out how the
> probe function on it gets called.
>
> The driver initialization function calls pci_register_driver:
>
> ->8
> static struct pci_driver e1000_driver = {
> .name = e1000_driver_name,
> .id_table = e1000_pci_tbl,
> .probe= e1000_probe,
> .remove = e1000_remove,
> // ...
> };
>
> static int __init e1000_init_module(void)
> {
> // ...
> ret = pci_register_driver(&e1000_driver);
> // ...
> }
> ->8
>
> And pci_register_driver is defined as (on linux/pci.h):
>
> ->8
> #define pci_register_driver(driver) \
> __pci_register_driver(driver, THIS_MODULE, KBUILD_MODNAME)
> ->8
>
> Function __pci_register_driver is defined as (drivers/pci/pci-driver.c):
>
> ->8
> int __pci_register_driver(struct pci_driver *drv, struct module *owner,
> const char *mod_name)
> {
> /* initialize common driver fields */
> drv->driver.name = drv->name;
> drv->driver.bus = &pci_bus_type;
> drv->driver.owner = owner;
> drv->driver.mod_name = mod_name;
>
> spin_lock_init(&drv->dynids.lock);
> INIT_LIST_HEAD(&drv->dynids.list);
>
> /* register with core */
> return driver_register(&drv->driver);
> }
> EXPORT_SYMBOL(__pci_register_driver);
> ->8
>
> This is the point where I am getting lost. I can't figure out how the Kernel
> will know about the functions defined in the e1000_driver struct mentioned
> before, since it does not seem to pass a reference to it anywhere.
>
> How does the kernel know where the probe function for this module is in this
> case? To be honest, for any driver that calls pci_register_driver, how will
> the
> kernel know where the probe function is since it does not seem like it is
> being passed to driver_register?
The magic is in the 'drv->driver.bus = &pci_bus_type;' assigment. This
is where the driver core will look for functions knowing how to handle
this specific driver. See Documentation/driver-model/bus.txt etc
Look at the defintion of pci_bus_type in drivers/pci/pci-driver.c :
struct bus_type pci_bus_type = {
.name = "pci",
.match = pci_bus_match,
.uevent = pci_uevent,
.probe = pci_device_probe,
.remove = pci_device_remove,
.shutdown = pci_device_shutdown,
.dev_groups = pci_dev_groups,
.bus_groups = pci_bus_groups,
.drv_groups = pci_drv_groups,
.pm = PCI_PM_OPS_PTR,
};
EXPORT_SYMBOL(pci_bus_type);
And then look at the different callbacks. These explain how the generic
&drv->driver above is turned back into a pci_driver on probing:
static int pci_device_probe(struct device *dev)
{
int error;
struct pci_dev *pci_dev = to_pci_dev(dev);
struct pci_driver *drv = to_pci_driver(dev->driver);
to_pci_dev() and to_pci_driver() are just macros simplifying the usual
container_of trick. From include/linux/pci.h :
#define to_pci_dev(n) container_of(n, struct pci_dev, dev)
..
#define to_pci_driver(drv) container_of(drv, struct pci_driver, driver)
Hope this helps.
Bjørn
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Found a problem so what next?
John Whitmore writes: I'm sure that this problem has been found and a patch submitted by now as it > seems to have been from months ago. But assuming neither had occured and this > was a new discovery how do you check for a reported bug? Do you search mailing > list for that commit number, or a part of that commit number? I cannot tell you what the best practice is, but at least that's what I do. Googling for a fix is usually pretty accurate once the problematic commit has been found. Both the short title and the 12 digit commit ID should work, because they are included in the "Fixes" tag of the fix. Unfortunately Googling isn't as accurate before you know the buggy commit. In an ideal world, you should be able to find the fix based on the symptoms described in the commit message. But this doesn't work well for symptoms which occur frequently and with varying causes. "suspend failing" is definitely one of those... And yes, it is common to discover what you did: The bug is already found and fixed, but the fix hasn't propagated yet. That can be a bit demotivating until you realize the beauty of a system where someone else already fixed your problem and documented the fix in a public "bug database" :) Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: git tags (RC kernels ) and kernel versions (www.kernel.org)
Kevin Wilson writes: > I want to be able to work with git commands with the Linux kernel > versions according to what I see > in www.kernel.org, and I encounter a difficulty. The following example > demonstrates the > difficulty I encounter. > > I see under: > https://www.kernel.org/pub/linux/kernel/v4.x/ > 13 sub version of the 4.1 kernel: > 4.1.1 > 4.1.2 > . > > > 4.1.13 > > > For each one there is a correspoinding ChangeLog ( ChangeLog-4.1.3, > ChangeLog-4.1.4, > and so on) > I know of course that I can find the commits for each such subversion > by looking in > the corresponding ChangeLog. However, I want to be able to work with > the different subversions > of 4.1 (for example) with git. This means to navigate with git > commands from, let's say, 4.1.13 to 4.1.5, and also go > back and forth with git commends to 4.0 and earlier versions. And also > of course see the commits by > "git show", see the history by "git log", and in general run all git commands. > > However, when I run in Linus tree > (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git) > the following: > > git tag | grep 4.1 > I get: > v4.1 > v4.1-rc1 > v4.1-rc2 > v4.1-rc3 > v4.1-rc4 > v4.1-rc5 > v4.1-rc6 > v4.1-rc7 > v4.1-rc8 > > So these 8 rc subversions of 4.1 do not seem to correspond the the > 1..13 subversions that I see > in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > as mentioned below. The '-rc' tags are release candidates, i.e. development snapshops of the 'v4.1 to be'. They are not releases and not directly related to 4.1.y revisions at all. Those are in a separate branch based on the final 4.1 release. You can find the 4.1.y stable branch, and other stable branches here: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/ Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: is there a reason "usbhid.quirks" parameter is not root writable?
"Robert P. J. Day" writes: > On Thu, 12 Nov 2015, Greg KH wrote: > >> You can add a runtime quirk to the device itself when it shows up in >> sysfs for the hid driver. Use that instead of the module parameter for >> that specific device. > > sorry, i'm not sure what you're suggesting here. I don't know if this was what Greg meant, but you can always use /sys/bus/usb/drivers/usbhid/unbind to unbind the device from the usbhid driver. Then you can manually bind it to some other driver supporting the same device using the same mechanism (with s/un// of course), or load another supporting driver to make it probe and bind the device. Hmm, I was going to point you to the file documenting bind/unbind for the usb bus, but it doesn't seem to exist? There you have a task for someone wanting to improve the docs :) Anyway, it goes like this: Look at the device driver binding in sysfs: $ ls -l /sys/bus/usb/drivers/usbhid total 0 lrwxrwxrwx 1 root root0 Nov 13 09:06 4-4:1.0 -> ../../../../devices/pci:00/:00:1d.7/usb4/4-4/4-4:1.0 --w--- 1 root root 4096 Nov 13 09:06 bind lrwxrwxrwx 1 root root0 Nov 13 09:06 module -> ../../../../module/usbhid -rw-r--r-- 1 root root 4096 Nov 13 09:06 new_id -rw-r--r-- 1 root root 4096 Nov 13 09:06 remove_id --w--- 1 root root 4096 Nov 13 09:06 uevent --w--- 1 root root 4096 Nov 13 09:06 unbind Unbind the device you want to move somewhere else: $ echo 4-4:1.0 >/sys/bus/usb/drivers/usbhid/unbind Bind it to 'otherdriver': $ echo 4-4:1.0 >/sys/bus/usb/drivers/'otherdriver'/bind (wich will only succeed of that driver's probe succeeds, of course. If you need to add a device ID to another driver, then do that using 'new_id' instead. Which will trigger automatic probing of 'free' devices) Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Enable/disable cpu
Doug Wilson writes:
> All,
>
> I have been looking at sysfs cpu side code. Had a quick question.
>
> On my x86 box:
> #ls /sys/devices/system/cpu/
> I see 4 cpus plus a few more fields such as online/present/possible etc.
>
> This come from drivers/base/cpu.c.
>
> My question here is, in each of those cpu0-3 folders, there's file by name
> online which one can use to disable/enable cpu using cpumask. Could
> someone point me to that code, I could not really pin point to where exactly
> this attribute is defined. Am just exploring cpu hotplug feature.
drivers/base/core.c has this generic code for creating that file:
if (device_supports_offline(dev) && !dev->offline_disabled) {
error = device_create_file(dev, &dev_attr_online);
if (error)
goto err_remove_dev_groups;
}
where device_supports_offline is:
static inline bool device_supports_offline(struct device *dev)
{
return dev->bus && dev->bus->offline && dev->bus->online;
}
and the cpu "bus" is (from drivers/base/cpu.c):
struct bus_type cpu_subsys = {
.name = "cpu",
.dev_name = "cpu",
.match = cpu_subsys_match,
#ifdef CONFIG_HOTPLUG_CPU
.online = cpu_subsys_online,
.offline = cpu_subsys_offline,
#endif
};
The fields of the cpu device are initialized in drivers/base/cpu.c:
int register_cpu(struct cpu *cpu, int num)
{
int error;
cpu->node_id = cpu_to_node(num);
memset(&cpu->dev, 0x00, sizeof(struct device));
cpu->dev.id = num;
cpu->dev.bus = &cpu_subsys;
cpu->dev.release = cpu_device_release;
cpu->dev.offline_disabled = !cpu->hotpluggable;
cpu->dev.offline = !cpu_online(num);
cpu->dev.of_node = of_get_cpu_node(num, NULL);
#ifdef CONFIG_GENERIC_CPU_AUTOPROBE
cpu->dev.bus->uevent = cpu_uevent;
#endif
cpu->dev.groups = common_cpu_attr_groups;
if (cpu->hotpluggable)
cpu->dev.groups = hotplugable_cpu_attr_groups;
error = device_register(&cpu->dev);
if (!error)
per_cpu(cpu_sys_devices, num) = &cpu->dev;
if (!error)
register_cpu_under_node(num, cpu_to_node(num));
return error;
}
So you get the "online" file in the cpuX folders when CONFIG_HOTPLUG_CPU
is defined and cpu->hotpluggable is true. Which will exclude cpu0 in
some cases. See arch/x86/kernel/topology.c for the x86 specific logic
concerning that. I assume other platforms have similar exceptions
Bjørn
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Would like know when the tcp sequence no is rollover
Ramana Reddy writes: > Hi Bjørn, > > Thanks for your reply. Actually, I want to do some small experiment, so > would need this tcp sequence roll over code. > If you know some thing in this regards, please let me know. There isn't much more to say, I think. All that's left is hard work. Since there is no existing rollover logic, you'll have to track down every single sequence number calculation in the kernel and modify them with additional rollover code. Note that this includes every sequence number comparison too. I'm afraid I still don't see the point. The end result will of course not be TCP anymore, and will only be capable of talking to itself. What use is that? Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Would like know when the tcp sequence no is rollover
Ramana Reddy writes: > Hi all, > > I would like to know, when the TCP sequence no is rollover. > Who will do it. Is it happens in tcp code or through the hardware. > If is it is in the tcp code, can some one please point the code in the > linux kernel > where it happens. Why this interest in TCP sequence numbers? I believe RFC793 is a better source for understanding how this works: It is essential to remember that the actual sequence number space is finite, though very large. This space ranges from 0 to 2**32 - 1. Since the space is finite, all arithmetic dealing with sequence numbers must be performed modulo 2**32. Do you still think you'll find an explicit rollover code path? Why would you write code like that? Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Use a variable before it's declaration
Rock Lee writes:
>> Rock Lee writes:
>>
>>> Hi, all:
>>> Here is a snippet of linux-v3.4 which drives me crazy.
>>> Because init_task hasn't been declared yet when init_thread_union is
>>> initializing. Why is there no compiling error? Any hint would be helpful.
>>>
>>> union thread_union init_thread_union __init_task_data =
>>>
>>> { INIT_THREAD_INFO(init_task) };
>>>
>>>
>>>
>>> /*
>>>
>>>* Initial task structure.
>>>
>>>*
>>>
>>>* All other task structs will be allocated on slabs in fork.c
>>>
>>>*/
>>>
>>> struct task_struct init_task = INIT_TASK(init_task);
>>
>>
>> Because init_task is declared "extern" in linux/sched.h
>>
>>
>> Bjørn
>
> I do something like that:
>
> extern int b;
> int a = b + 10;
> int b = 20;
>
> int main(void)
> {
> return 0;
> }
>
> No doubt, compiling error.
Sure. That's a completely different issue. But this works:
extern int b;
int *a = &b;
int b = 20;
int main(void)
{
return 0;
}
and that's what the code you refer do does.
Bjørn
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Use a variable before it's declaration
Rock Lee writes:
> Hi, all:
> Here is a snippet of linux-v3.4 which drives me crazy.
> Because init_task hasn't been declared yet when init_thread_union is
> initializing. Why is there no compiling error? Any hint would be helpful.
>
> union thread_union init_thread_union __init_task_data =
>
> { INIT_THREAD_INFO(init_task) };
>
>
>
> /*
>
> * Initial task structure.
>
> *
>
> * All other task structs will be allocated on slabs in fork.c
>
> */
>
> struct task_struct init_task = INIT_TASK(init_task);
Because init_task is declared "extern" in linux/sched.h
Bjørn
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: SHA-1 hash calculate in Kernel.
lx writes:
> hi all:
> I built a module for calculate the SHA-1. The code is:
> ##
> #include
> #include
> #include
> #include
> #include
> #include
> MODULE_LICENSE("Dual BSD/GPL");
>
> #define SHA1_LENGTH 20
>
> static int hello_init(void)
> {
> /*
> * http://lxr.oss.org.cn/source/fs/ecryptfs/crypto.c?v=2.6.30
> */
> struct scatterlist sg;
> struct hash_desc desc;
>
> //way 1
> /*
> char *plaintext = "c";
> size_t len = strlen(plaintext);
> */
>
> //way 2
> /*
> char *plaintext = kmalloc(sizeof(char), GFP_KERNEL);
> plaintext = "c";
> size_t len = 1;
> */
>
> // way 3.
> /*
> char plaintext[1] = {'c'};
> size_t len = 1;
> */
>
> // way 4.
> /*
> char *plaintext = (char *)__get_free_page(GFP_KERNEL);
> memcpy(plaintext, "c", 1);
> size_t len = 1;
> */
>
> int rc = 0;
> int i;
> char hashtext[SHA1_LENGTH];
>
> memset(hashtext, 0x00, SHA1_LENGTH);
> printk(KERN_INFO "sha1: %s\n", __FUNCTION__);
>
> sg_init_one(&sg, plaintext, len);
> desc.tfm = crypto_alloc_hash("sha1", 0, CRYPTO_ALG_ASYNC);
> desc.flags = 0;
>
> rc = crypto_hash_init(&desc);
> if (rc) {
> printk(KERN_ERR "%s: Error initializing crypto hash; rc = [%d]\n",
> __func__, rc);
> goto out;
> }
> rc = crypto_hash_update(&desc, &sg, len);
> if (rc) {
> printk(KERN_ERR "%s: Error updating crypto hash; rc = [%d]\n",
> __func__, rc);
> goto out;
> }
> rc = crypto_hash_final(&desc, hashtext);
> if (rc) {
> printk(KERN_ERR "%s: Error finalizing crypto hash; rc = [%d]\n",
> __func__, rc);
> goto out;
> }
> crypto_free_hash(desc.tfm);
>
> for (i = 0; i < 20; i++) {
> printk(KERN_INFO "%02x-%d\n", hashtext[i]&0xff, i);
> }
>
> out:
> printk(KERN_INFO "end\n");
> return rc;
> }
>
> static void hello_exit(void)
> {
> printk(KERN_ALERT "Goodbye, cruel world\n");
> }
>
> module_init(hello_init);
> module_exit(hello_exit);
> ##
> I can just get the right result by way 3 and 4, In way 1 and 2 , I get the
> wrong result,
I suggest you add something like this:
printk(KERN_INFO "plaintext='%c', len=%zu, valid=%s\n", *plaintext, len,
virt_addr_valid(plaintext) ? "true" : "false");
and then go figure out the relationship between that and the correct
result :)
Bjørn
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Newbie help
Rishabh Chakrabarti writes: > Hello all, > > Where can I search the archives and other resources for answering the > following questions: > > 1. How to dive into the code? i.e. entry points Wherever your interest is. There are no strict rules. If you don't know ahere your interest is, then you should ask yourself why you are interested in the Linux kernel in the first place. Out of your areas of interest, try to find a part of the kernel which is well maintained and have (semi-)sufficient reviewer resources, because you will need that as a newbie. You may use the Status field in MAINTAINERS as an initial guide, but only recent mailing list archives will tell for sure. Look for comments and feedback on patches. > 2. What are the pre-requisites for understanding the whole code? I don't think that is possible... You should understand the part you want to modify. You'll need some knowledge of C, and an ability to learn. The latter is most important. > 3. Best books and resource material I see that Documentation/ and LDD3 is already mentioned. Other than that: The source code is there, and is much more readable and commented than most other C projects. Use it. Reading code, and trying to figure out how it works and why it was written like that, is a great way to learn. Use the git commit messsages to help understanding if there is something which isn't obvious (there will be, of course). Every single commit is justified and explained and in detail in git. And you will have to do the same, so you should familiarize yourself with those messages in any case. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel contributions from organisations and individual privacy
Jeff Haran writes: > What is the downside to a large company for violating GPL? Losing all rights to the software in question forever is probably the largest downside. If we talk about the Linux kernel (as I assume we do in this forum) then I have a hard time believing any company can survive that. Note that loosing the rights to use the Linux kernel will not only affect the products your company produce, but also your rights to *use* any Linux based product. The legal department would also end up with a limited selection of phones they could legally use. So, I'd say the downside is infinite. Why do companies still risk this? For little or no gain whatsoever? Or even negative gain, since we all know that you get many times back for every contribution you make to open source. I guess it is the result of tech staff and legal staff not talking together. The legal staff will hopefully have some understanding of the GPL, and know that violating it leaves them without any rights to the software in question. But they will probably assume that those rights are for sale, or that it is possible to buy the rights to an equivalent software product. The technical staff will know that this is impossible, but they are probably not aware of the finer details of the GPL. So there you go: Noone understand the full consequences. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Userpace serial port
Ricardo Ribalda Delgado writes: > I want to use the serial userspace api. But I do not want to write a > kernel module. I really like the design of uinput, and I would like to > use something similar here. Do you need the modem control lines, or would a pty be good enough for your use case? If you need more than that, then you could probably do a complete serial driver using CUSE. But you would have to copy a lot of kernel code to userspace. It is much easier to just write a kernel driver. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How .suspend and .resume are invoked
Anand Moon writes: > hi All, > > I would like to know how .suspend and .resume > in device driver invoked where ACPI is not used. https://www.kernel.org/doc/Documentation/power/devices.txt > What I meant is suppose you have USB not connected > then what is the state of the device driver. > > Is the .probe function running continuously in the background. No. Now your into USB hotplug, aren't you? But if this is related to suspend/resume, then it's probably answered by https://www.kernel.org/doc/Documentation/usb/power-management.txt Sorry for only pointing to further reading, but I'm definitely not capable of answering any better than the experts who have written those documents. And I seriously doubt anyone else is either - with the possible exception of those experts. And they shouldn't have to repeat their answers when they have taken the time to write excellent docs, should they? Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How to install a older version kernel on new OS?
Gao Peng writes: > I am using fedora 21,and kernel version is 3.17 but I compile a 2.6.32 > kernel and install it, That does not make sense. Really. > when I reboot I got error :"too old kernel", Which is correct. Note that this is still correct even if you can make that warning go away. > how Can I install a rather older kernel on a new system,is there some > way fix it? Install some ancient distro that came with a 2.6.32 kernel. It will have all the matching userspace applications. But this seems like a complete waste-of-time project. Care to share the reasons why you'd want to do something like that? Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How to read write PCI BAR memory address
Anil Joshi writes: > My PCI device information is as follows: > > Print Begin Configuration space... > BAR 0 start address: f600 > BAR 0 end address: f6ff > BAR 0 flags: 140204 > BAR 0 IO / MEM: MEM > BAR 0 PREFETCH NON PREFETCH: NON-PREFETCH > BAR 1 start address: 0 > BAR 1 end address: 0 > BAR 1 flags: 0 > BAR 1 IO / MEM: MEM > BAR 1 PREFETCH NON PREFETCH: NON-PREFETCH > BAR 2 start address: f000 > BAR 2 end address: f3ff > BAR 2 flags: 14220c > BAR 2 IO / MEM: MEM > BAR 2 PREFETCH NON PREFETCH: PREFETCH > > I want to write a byte and read it back to BAR2 for a test simple . Is it > possible to write a byte to BAR2 start address > > > Sample code is welcomed. Linux export these resourses in sysfs. See See https://www.kernel.org/doc/Documentation/filesystems/sysfs-pci.txt Googling for these will get you some usage examples, like this one: http://billfarrow.blogspot.com/2010/09/userspace-access-to-pci-memory.html Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Question about assembly in set bit function for x86 architecture
valdis.kletni...@vt.edu writes: > On Sun, 19 Apr 2015 19:08:17 -0400, Nicholas Krause said: > >> The reason I am asking is that is assembly worth my time to learn for this >> part of the kernel, I understand it's use in boot code but outside of that >> and >> cache memory lines in architecture directories there is very little, 95 >> percent >> of the kernel is written in C. In addition due to this the only practical >> reason I can thing of is for debugging, how useful is assembly for kernel >> debugging is my other question about this topic. > > We're not going to bail you out here, Nick. Either learn enough assembly > to answer your question, or don't obsess over one line of code and assume > it works. It's not necessary to limit this advice by language or specific lines of code. NO part of the kernel can be understood without investing some time trying to learn. But fear not - there is a shortcut available for those (assuming there might be more than one) who refuse to learn: Assume it works. OK, I'll admit taking that route more than once myself :-) Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Question about ixgbe and ixgbevf
Kevin Wilson writes: > Hi, > I have an x86_64 machine (F21) on which ixgbevf is not loaded. > I notices that when running > modprobe ixgbevf max_vfs = 10 (or any other number), this triggers > loading of ixgbevf driver. > I will appreciate if someone can exaplain the implementation details > of how does this happen. > I could not find what in the ixgbe driver code triggers this action max_vfs is a deprecated method for setting an initial value for adapter->num_vfs. You'll normally use sysfs to add VFs today. If you look at this extremely over-long ixgbe_probe() function in ixgbe_main.c then you'll find this: pci_sriov_set_totalvfs(pdev, IXGBE_MAX_VFS_DRV_LIMIT); ixgbe_enable_sriov(adapter); ... and then looking at ixgbe_enable_sriov() in ixgbe_sriov.c : err = pci_enable_sriov(adapter->pdev, adapter->num_vfs); If you're interested in the gory details here, then I suggest looking at Documentation/PCI/pci-iov-howto.txt . But it is sufficient to know that this creates a number of new PCI devices with IDs which is then matched by the ixgbevf driver. That driver will then be autoloaded and probed for all the new VF PCI devices, just like any other hotplugged PCI device works. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: confusing code....whats the point of this construct ?
valdis.kletni...@vt.edu writes: > On Wed, 11 Mar 2015 18:37:32 -, Jeff Haran said: > >> I don't understand the problem here. The caller passes in a condition to be >> evaluated in a loop. Many times that condition is quite simple (e.g. a >> counter >> being non-zero). If it was a function the caller would have to pass in a >> pointer to a function that does the evaluation, as in: > > We do pointers to callback functions all the time. We try *really* hard > to avoid anonymous lambda functions (which is basically what we have here). > > The problem here is that there's about 3 zillion ways to screw up the inline > version, starting with the compiler optimizing the control variable into a > hoisted load outside the loop and causing the test to always fail - note that > the macro does *not* use any barriers or volatile or anything like that. We could go a couple of more rounds on this, but I don't think there is much point. It is sufficent to note that there are different views on the subject. None of them are "right" or "wrong". Use a function if you like. There are probably 3 zillion ways to screw up either way :-) Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: confusing code....whats the point of this construct ?
valdis.kletni...@vt.edu writes: > On Wed, 11 Mar 2015 15:17:44 +0100, Nicholas Mc Guire said: > >> So the wait_event_timeout condition here ends up being (empty || skip) >> but what is the point of puting this code into the parameter list of >> wait_event_timeout() ? >> >> Would it not be equivalent to: >> >> bool empty; >> ... >> >> spin_lock_bh(&ar->htt.tx_lock); >> empty = (ar->htt.num_pending_tx == 0); >> spin_unlock_bh(&ar->htt.tx_lock); >> >> skip = (ar->state == ATH10K_STATE_WEDGED) || >> test_bit(ATH10K_FLAG_CRASH_FLUSH, >> &ar->dev_flags); >> >> ret = wait_event_timeout(ar->htt.empty_tx_wq, (empty || skip), >> ATH10K_FLUSH_TIMEOUT_HZ); >> >> What am I missing here ? > > Umm... a Signed-off-by: and formatting it as an actual patch? :) > > Seriously - you're right, it's ugly code that needs fixing... Huh? The condition needs to be re-evaluated every time the process wakes up. Evaluating it once and then reusing that result is not the same. Something elseis supposed to modify ar->htt.num_pending_tx, ar->state or ar->dev_flags while we are waiting. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: why is "const u32 (*tab)[256]" not kerneldoc-able?
"Robert P. J. Day" writes: > actually, i just found where this is a known issue: > > http://www.spinics.net/lists/linux-doc/msg09364.html Probably because it's a rare construct. But looking closer at this, trying to understand why the simple test using scripts/kernel-doc lib/crc32.c |man -l - seemed to sort of work, I found that your main problem isn't really the lack of kernel-doc support for array pointer parameters. It's a simple mismatch between the documented and the exported functions. scripts/docproc will only generate docs for exported symbols. lib/crc32.c has no documented *and* exported functions, and thats why the output is empty. The array pointer is a red herring. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: why is "const u32 (*tab)[256]" not kerneldoc-able?
Bjørn Mork writes: > Maybe the attached simple patch is good enough? Completely untested > except for a single run against that file Ah, umh, no. That "const u32 (*)[256] tab" does not look correct: crc32_le_generic(9) Kernel Hacker's Manual crc32_le_generic(9) NAME crc32_le_generic - Calculate bitwise little-endian Ethernet AUTODIN II CRC32/CRC32C SYNOPSIS u32 __pure crc32_le_generic (u32 crc, unsigned char const *p, size_t len, const u32 (*)[256] tab, u32 polynomial); ARGUMENTS crc seed value for computation. ~0 for Ethernet, sometimes 0 for other uses, or the previous crc32/crc32c value if computing incrementally. p pointer to buffer over which CRC32/CRC32C is run len length of buffer p tab little-endian Ethernet table polynomial CRC32/CRC32c LE polynomial I guess a proper fix is needed. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: why is "const u32 (*tab)[256]" not kerneldoc-able?
"Robert P. J. Day" writes:
> when generating the kerneldoc manual kernel-api.html with "make
> htmldocs", the two routines in lib/crc32.c that refer to a parameter
> of type "const u32 (*tab)[256]" generate kerneldoc errors:
>
> Warning(.//lib/crc32.c:148): No description found for parameter 'tab)[256]'
> Warning(.//lib/crc32.c:148): Excess function parameter 'tab' description in
> 'crc32_le_generic'
> Warning(.//lib/crc32.c:293): No description found for parameter 'tab)[256]'
> Warning(.//lib/crc32.c:293): Excess function parameter 'tab' description in
> 'crc32_be_generic'
> Warning(.//lib/crc32.c): no structured comments found
>
> kerneldoc content and declaration for one of them:
>
> /**
> * crc32_le_generic() - Calculate bitwise little-endian Ethernet AUTODIN II
> * CRC32/CRC32C
> * @crc: seed value for computation. ~0 for Ethernet, sometimes 0 for other
> * uses, or the previous crc32/crc32c value if computing incrementally.
> * @p: pointer to buffer over which CRC32/CRC32C is run
> * @len: length of buffer @p
> * @tab: little-endian Ethernet table
> * @polynomial: CRC32/CRC32c LE polynomial
> */
> static inline u32 __pure crc32_le_generic(u32 crc, unsigned char const *p,
> size_t len, const u32 (*tab)[256],
> u32 polynomial)
> {
>
> ... snip ...
>
> so what is it about that declaration that causes kerneldoc to choke?
> and because those two routines are the only kerneldoc content in that
> source file, the kernel-api page generated for that file is just a
> dummy page, reporting an error.
>
> thoughts?
Maybe the attached simple patch is good enough? Completely untested
except for a single run against that file
Bjørn
>From 3da3a4c052d534eb34b1dd91362dc0b05f232d57 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B8rn=20Mork?=
Date: Tue, 3 Feb 2015 14:15:48 +0100
Subject: [PATCH] kernel-doc: support pointer-to-array params
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Bjørn Mork
---
scripts/kernel-doc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 9922e66883a5..1143f80f07ed 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -1877,8 +1877,8 @@ sub create_parameterlist($$$) {
# corresponding data structures "correctly". Catch it later in
# output_* subs.
push_parameter($arg, "", $file);
- } elsif ($arg =~ m/\(.+\)\s*\(/) {
- # pointer-to-function
+ } elsif ($arg =~ m/\(.+\)\s*(?:\(|\[)/) {
+ # pointer-to-function or -array
$arg =~ tr/#/,/;
$arg =~ m/[^\(]+\(\*?\s*(\w*)\s*\)/;
$param = $1;
--
2.1.4
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: New member
John de la Garza writes: > On Sun, Jan 25, 2015 at 08:10:15PM +, Anuz Pratap Singh Tomar wrote: >> On Sun, Jan 25, 2015 at 7:38 PM, srinivas bakki >> wrote: >> >> > Valdis, >> >You got to be polite with people.Not everybody is as smart as >> > you, but they would like to contribute. Just keep in in mind that there's >> > no future for linux without such people. You cannot keep bullying everybody >> > like this. >> > >> >> Talking about polite, you are Top posting, how rude is that? > > I thought the post was very helpfull and not rude at all. I guess we > all perceive things differently. This document is written for the Debian project, but I believe it's a good guide to any open mailing list: https://www.debian.org/code_of_conduct I am pretty sure all participants in this thread are trying to help. But I will ask you all to consider the "In case of problems" section of that document before continuing this discussion. In particular: "Assume good faith; it is more likely that participants are unaware of their bad behaviour than that they intentionally try to degrade the quality of the discussion." In my experience, you will miss a lot if you disregard articles you find "rude". Direct and concise advice might sometimes come out harsher than it was meant. It doesn't make the advice any less worth. On the contrary. Thanks, Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Debugging an ARP issue (no resp to ARP requests)
Mandeep Sandhu writes: > Hi All, > > Please let me know if this is not the correct ML for such a question > (or if there's a more appropriate list for it). > > I'm currently debugging an issue where Linux is not responding to ARP > requests (testing with custom network interface h/w). > > I have 2 network interfaces which are basically interfaces on a custom > network device sitting on the PCI bus. > > My setup looks like follows: > > xeth0 - 192.168.2.1 > xeth2 - 192.168.2.2 > > xeth0/2 are the interfaces created for the custom device (via a lkm) > > Both these interfaces are on the local machine and are connected > back-to-back on the custom device, so packets sent from one arrive on > the other. This won't work. Linux will consider both addresses as local to the host and will never respond to arp requests from any of those addresses. See http://en.wikipedia.org/wiki/Host_model You might be able to change this by tuning arp_announce/arp_ignore - But I don't know if that changes the behaviour wrt responses to local addresses... See https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt for the meaning of these knobs. If your main interest is to test how Linux (or your driver/hardware) responds to ARPs, then it's definitely easiest/best to use two Linux hosts. This might of course be two virtual hosts running on the same hardware if you have hardware restrictions. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Wait times for patch submission
Mandeep Sandhu writes: > Hi All, > > I wanted to check with ppl who frequently post patches to LKML on how > long should one should wait before resending the patches in case > there's no response to them. That depends on lots of factors. Like how important the patch is, what kind of patch management system the maintainer uses, etc, etc. > I had sent a patch on Greg KH's staging-next tree, on 16 Dec '14 to > LKML and the relevant maintainers. > > I got a mail from Greg's friendly bot stating that the branch was > closed and that the patches will be looked at once the merge window > closes. Which usually (always?) is true. Note that "once the merge window closes" doesn't necessarily mean within days after -rc1. It might mean a few weeks if the maintainer is busy doing other stuff, like travelling etc. And maintainers are always busy :-) Some maintainers even have a life, which implies taking time off with their family at this time of the year. You should therefore give them a week or two extra slack. And no, this does not count as "no response". You got a reply giving a precise description of how your patches will be handled and what you need to do. > Do I need to resend the patches again or will they be picked up from > the maintainer's queue? They will most likely be picked up as promised, and you'll get another mail telling you which tree they were added to. I would wait until at least -rc5 in any case before considering a repost of something destined for the next release. That still leaves plenty of time before the next merge window opens. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: newbies CheckpatchTips for multiline statements (Breaking function calls)
Joe Perches writes:
> This style is fine, and generally perferred. However, some driver
> writers prefer to have the trailing line of a function call line up with
> the starting '('. They use tabs, followed by spaces, to align the
> trailing line:
>
>
> pdata->urbdata = usb_alloc_coherent(pdata->udev, ACD_URB_BUFFER_LEN,
> GFP_KERNEL,
> &pdata->urb->transfer_dma);
It might be worth noting that the network subsystem maintainer prefers
this style as well. So most networking patches should probably use it.
The exception would be files which already use the other style.
You should also be aware of the implications of this style: You have to
modify all three lines if you change anything on the first line causing
the position of the starting '(' to change. I.e., a patch like this is
not acceptable:
-pdata->urbdata = usb_alloc_coherent(pdata->udev, ACD_URB_BUFFER_LEN,
+p->urbdata = usb_alloc_coherent(pdata->udev, ACD_URB_BUFFER_LEN,
GFP_KERNEL,
&pdata->urb->transfer_dma);
It needs to be
-pdata->urbdata = usb_alloc_coherent(pdata->udev, ACD_URB_BUFFER_LEN,
-GFP_KERNEL,
-&pdata->urb->transfer_dma);
+p->urbdata = usb_alloc_coherent(pdata->udev, ACD_URB_BUFFER_LEN,
+GFP_KERNEL,
+&pdata->urb->transfer_dma);
Bjørn
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Query on git usage for creating patch with incremental commits
Kumar Amit Mehta writes: > So far so good, but what If, I am not particularly proud of the first > patch, but have to send that anyway, If my patches are to be applied. > Another approach would be to create another branch, say development-again, > based of origin/master and make the necessary changes and then just > create one patch file. But I was wondering that while doing development, > don't we make commits in our working branches, which we think is > correct, only to find it ridiculous later (say after few more commits > in future) ? And what to do in such scenario ? Or how to use git to > solve such scenario. git rebase is made for things like this. See http://git-scm.com/book/en/v2/Git-Tools-Rewriting-History Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: List my Staging Drivers
Lucas Tanure writes: > How do I list where are the modules that I'm using inside kernel ? lsmod The actual drivers you are using: ls -l /sys/bus/*/devices/*/driver Or look at the output of lsusb, lspci etc. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Filtering noise is about protecting resourses (was: Re: Remove Ban?)
Philipp Muhoray writes: > Not that I have any say in this, but I feel like a ban should rather > be justified by someone's behavior instead of incorrect patches. It's not a ban, it's a protective filter. Maintainers and reviewers are limited resources. We should not waste them. > I > guess most of us have send awful patches at some point, the question > though is how we dealt with it. I'm not saying the ban should be > lifted, I'm just saying we should communicate the right arguments for > his ban (instead of blaming him for commit messages he didn't even > write). If you look at what actually happened, you'll see a very good example of why the filter is still required: The original patch was yet another completely pointless fixme-comment deletion, without any real explanation whatsoever in the commit message. And it wasn't even properly formatted with a subsystem prefixed subject etc. So the maintainer had to spend time trying to fix up the commit message and figuring out why it was OK to delete those fixme comments. As has been pointed out here, that explanation could still be incomplete. I guess the maintainer didn't want to spend hours looking at something as pointless as this. The problem is that he didn't realize that this patch was a waste of time before spending time on it at all. Which is exactly why the maintainers should be protected against having to look at stuff like this, if possible. And in this case it *is*. There are exactly zero examples of valuable patches from that author. If you look at the history of accepted patches, you will find that in each and every case there is some reviewer or maintainer doing the *real* work - figuring out that the patch is OK and explaining why. And the result is still patches without any real value. They don't solve any problem for anyone. They are the result of stupid and mindless grepping for a specific word in comments. Yes, we have all wasted time for maintainers and reviewers by sending them stuff we shouldn't have. That's part of the game. The problem in this case is the massive distribution over an insane number of subsystems in combination with the inability to learn anything at all. Wasting one maintainer's time once is excusable. Wasting hundreds of maintainer's time over and over again is absolutely not. It's potentionally destructive to the whole project if it is allowed to continue. This very thread is yet another example of the contentless noise from this source, and I hate myself for having wasted your time having to read this. Sorry about that. But I write it in the hope that you will understand that the filtering is *not* about punishing anyone. It is about protecting or most valuable resources. And if anyone still wonders: Requests for "ban removal" has no value to the community, and are therefore the exact opposite of what's required to have the filter removed. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Possible error in debugfs/file.c
land.h...@gmail.com writes:
> I'm just reading the kernel source and came across this which doesn't look
> quite right to me:
> 616 size_t size = strlen(file->private_data);
>
> strlen is used here when the pointer points to type:
> 567 struct array_data {
> 568 void *array;
> 569 u32 elements;
> 570 };
No, it doesn't. file->private_data points to a string buffer allocated
in u32_array_open() and filled with a string representation of the
struct array_data, using u32_format_array().
So calling strlen() on it is perfectly valid and reasonable.
Bjørn
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: viewing pr_debug messages
Thomas Gummerer writes: > Kevin Wilson writes: > >> I am using journalctl -kf or journalctl -k >> to see kernel log messages. >> >> However, messages of "pr_debug" are not shown by this commands. >> >> Is there some way to view pr_debug kernel messages with journalctl -k ? > > pr_debug messages is usually an empty macro, unless it is explicitly > enabled by using -DDEBUG in the Makefile for the specific file. > > see: https://www.kernel.org/doc/local/pr_debug.txt Yes, but you should also see: https://www.kernel.org/doc/Documentation/dynamic-debug-howto.txt Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] staging: Fix spacing between function name and parentheses
valdis.kletni...@vt.edu writes:
> On Mon, 20 Oct 2014 09:17:50 -, el_es said:
>
>> Maybe better to introduce a standard clear marker that
>> able people just respond with, to alikes of nick:
>>
>> REJECTED-by: Name
>
> We already do something like this.
>
> You'll on occasion see 'Nacked-By: ...' go by when a kernel hacker
> wants to denote their displeasure with a given patch. It's up to the
> maintainer to decide how much credence to give to the Nack, based on the
> relative reputations of the person submitting the patch and the person
> nacking it, and any technical grounds given with the nack.
>
> So for instance, if Al Viro sticks a Nacked-By: on a submission, it's
> going to be *really* hard to get a maintainer to accept the patch, because
> Al has a very long history of almost always being right about such things.
Yes, but the technical grounds are still the reason the patch is not
accepted. Which is why a formalized nak is pointless. It has no value
without a verbose explanation of the technical grounds behind it. If Al
Viro, or anyone else, use a simple one-line reject message, then I am
pretty sure that is because they have already explained their objections
somewhere else. I don't think anyone can reject anything merely on their
personal reputation. And there is nowhere to record naks, so a standard
label just isn't needed.
Rejecting is completely different from e.g. Acked-by, which both is a
complete explanation ("I am fine with this patch as it is") and is
recorded for future reference in the commit message.
Bjørn
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: a couple other common patch submission boo boos
"Robert P. J. Day" writes: > oh, and while i'm here, i'm going to point out a couple other things > you should avoid if you're trying to get your first patch into the > kernel -- unsurprisingly, nick has violated both of these guidelines a > number of times. > > first, good grammar. seriously, good grammar. if you can't use > proper grammar for the single-line "Subject" field, you really have no > business submitting patches. > > and second, your explanation for the patch (what goes into the > commit log) should *match* the patch. in particular, do not claim that > you are fixing an "error" when all you're doing is cleaning up a > *warning*. nick is a major violator of this prime directive -- do not > categorize something as an "error" if it isn't. end of story. I do understand who you are addressing here, but I fear this is a little like a school teacher asking the children to be quiet - Those who listen are never the ones you want to shut up... So, with that in mind, I'd like to disagree about *first* patch requirements. The only way you can truly screw up your first kernel patch, is by not submitting it. It's of course always an advantage to have read and followed any advice you have found. And with everything indexed by a search engine, you are expected to have found some. But not everything. Do not worry, you will be politely pointed to the rest if necessary. For subsequent submissions you are of course required to read all comments and fixup the issues that are pointed out, so you might as well fix as much as possible before the first submission. But you shouldn't worry about posting a patch with some unresolved issues you weren't aware of, if it's your first kernel patch submission ever. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: ?
Ravi Raj writes: > We want to design our own coustom board and we dont > want to depend on the Board support package vendors. I don't think any vendor forces you to use their support. You can buy any board and develop your own Linux support for it, completely ignoring whatever BSP the vendor provides. But as others already mentioned: This seems like a lot of redundant work for no point whatsoever. At least no point I get... Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: none
valdis.kletni...@vt.edu writes: > On Fri, 29 Aug 2014 16:58:26 +0200, Ravi Raj said: >> so first step is to find an imx6 Arm a9 board and port linux to it > > Why not get an imx6 board that already *HAS* Linux for it? Where do you get one which *hasn't*? Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Workflow improvements when sending patches with format-patch && send-email ?
Matthias Beyer writes: > Hi, > > I have a problem related to my workflow when patching kernel sources. > What I do by now, when sending patches: > > scripts/get_maintainer.pl --file my/patched/file.c > > git format-patch -s -n --cover-letter > # and then appending _every single mail from the get_maintainer.pl > # call with either --to or --cc > # and the commit range You don't really need to append the addresses in this step. Using --to and --cc with "git send-email" is sufficient. > git send-email --no-chain-reply-to > # and then appending _every single mail from the get_maintainer.pl > # call with either --to or --cc > ./00* > > The second step is mainly copy-paste from the format-patch call, but I > guess you already notice my issue: I have to "hand-copy" every email > address from the get_maintainer.pl call. > > I also send my patches to two persons which do not get listed from the > get_maintainer.pl call most of the time, plus I do not send my patches > to the LKML directly (but the driverdev ML). > > I consider this hard work, especially when having a lot of _small_ > patchsets, as I do this for every single patchset and it really annoys > me. > > Are there tools somewhere to simplify these steps? Something like > > "generate & send patches from bla-blubb...foobazbar" > > and then it: > > 1) Gets mailaddrs from get_maintainer.pl > 2) lets me add additional and delete receivers > 3) asks me which one gets a --to and which one a --cc > 4) generates the patches with format-patch > 5) (optionally) runs checkpatch.pl on it > 6) sends the patches with send-email after confirmation I don't think we want to automate the last step. Kernel coders are fast learners and "confirmation" is quickly turned into automatically pressing 'y' without thinking... > Are there some tools out there? Or how do you guys do this? Or are > there tweaks built-in in git that I don't know yet? I have wondered about the same thing wrt get_maintainer.pl and git send-email. You can of course script this somewhere else, but it seems to me that a new switch to get_maintainer.pl creating a suitable would be useful? (Note that the copy/paste can be made easier by using the existing switches: scripts/get_maintainer.pl --nomultiline --separator ", --cc=" --file my/patched/file.c but this can still be improved a lot) Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Skb Documentation?
Nick Krause writes: > After searching around in the documentation directory, I need no > information on skb data structure and other information relating to > skb > data type. If someone knowns where there is Documentation in the > kernel directory please tell me, otherwise I would be glad to write > up. Instead of repeating myself: https://lkml.org/lkml/2014/7/23/610 Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: sysfs bind/unbind attributes usage
Raghavendra writes: > Hello, > > I would like to know more about manually probing/removing the devices > through sysfs attributes. > After searching for a while I came across two attributes 'bind' and > 'unbind' present in all the drivers. > > Now how may I correctly use them to probe my devices. > I sense the probing syntax is different for different kinds of drivers > (I2C, SPI, PCI, USB, etc). > I am mainly looking for probing I2C and SPI devices. sysfs attributes are supposed to be documented under 'Documentation/ABI/' but there seems to be a few holes there: bjorn@nemi:/usr/local/src/git/linux$ git grep bind Documentation/ABI/ Documentation/ABI/testing/configfs-usb-gadget: UDC - bind a gadget to UDC/unbind a gadget; Documentation/ABI/testing/configfs-usb-gadget: to bind a gadget, empty string "" to unbind. Documentation/ABI/testing/sysfs-bus-pci:What: /sys/bus/pci/drivers/.../bind Documentation/ABI/testing/sysfs-bus-pci:the driver to attempt to bind to the device found at Documentation/ABI/testing/sysfs-bus-pci:bindings. The format for the location is: :BB:DD.F. Documentation/ABI/testing/sysfs-bus-pci:# echo :00:19.0 > /sys/bus/pci/drivers/foo/bind Documentation/ABI/testing/sysfs-bus-pci:What: /sys/bus/pci/drivers/.../unbind Documentation/ABI/testing/sysfs-bus-pci:driver to attempt to unbind from the device found at Documentation/ABI/testing/sysfs-bus-pci:bindings. The format for the location is: :BB:DD.F. Documentation/ABI/testing/sysfs-bus-pci:# echo :00:19.0 > /sys/bus/pci/drivers/foo/unbind Documentation/ABI/testing/sysfs-bus-pci:for the device and attempt to bind to it. For example: Documentation/ABI/testing/sysfs-bus-pci:to driver_override will have an opportunity to bind to the Documentation/ABI/testing/sysfs-bus-pci:This returns the device to standard matching rules binding. Documentation/ABI/testing/sysfs-bus-pci:Writing to driver_override does not automatically unbind the Documentation/ABI/testing/sysfs-bus-pci:will not bind to any driver. This also allows devices to Documentation/ABI/testing/sysfs-bus-pci:opt-out of driver binding using a driver_override name such as Documentation/ABI/testing/sysfs-bus-usb:for the device and attempt to bind to it. For example: I am pretty sure patches to fix this are accepted... The bind/unbind attributes normally (always?) take a bus specific device name as input. I.e something like the ':00:19.0' shown above for PCI, or '4-2:1.2' for USB. > Also I found related attributes called 'new_id and remove_id' (for PCI > drivers) and also 'new_device and delete_device' (present in the i2c > adapter devices). These are better documented: bjorn@nemi:/usr/local/src/git/linux$ git grep new_id Documentation/ABI/ Documentation/ABI/testing/sysfs-bus-pci:What: /sys/bus/pci/drivers/.../new_id Documentation/ABI/testing/sysfs-bus-pci:# echo "8086 10f5" > /sys/bus/pci/drivers/foo/new_id Documentation/ABI/testing/sysfs-bus-pci:that was dynamically added via the new_id sysfs entry. Documentation/ABI/testing/sysfs-bus-usb:What: /sys/bus/usb/drivers/.../new_id Documentation/ABI/testing/sysfs-bus-usb:# echo "8086 10f5" > /sys/bus/usb/drivers/foo/new_id Documentation/ABI/testing/sysfs-bus-usb:# echo "0458 7045 0 0458 704c" > /sys/bus/usb/drivers/foo/new_id Documentation/ABI/testing/sysfs-bus-usb:# cat /sys/bus/usb/drivers/foo/new_id Documentation/ABI/testing/sysfs-bus-usb:What: /sys/bus/usb-serial/drivers/.../new_id Documentation/ABI/testing/sysfs-bus-usb: "/sys/bus/usb/drivers/.../new_id" apply. Documentation/ABI/testing/sysfs-bus-usb:that was dynamically added via the new_id sysfs entry. Documentation/ABI/testing/sysfs-bus-usb: "/sys/bus/usb/drivers/.../new_id" > Now how are they different from the bind/unbind > attributes, because as far as I know, even they do the same thing. No, they do different things. The bind/unbind attributes tries to attach/detach a driver to/from a device supported by that driver. The new_id/remove_id attributes adds/removes device IDs to/from the list of devices supported by the driver. Adding a new device ID to a driver will usually cause previously unbound devices with a matching ID to be bound though, which I guess is the part confusing you. > Could any one guide me through any documentation regarding all these issues Looks like you'll have to write some of that documentation ;-) Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewb
Re: about pr_debug
Varka Bhadram writes: > refer this :https://www.kernel.org/doc/local/pr_debug.txt That seems a little outdated since it doesn't mention the extremely useful dynamic debug feature. So please read https://www.kernel.org/doc/Documentation/dynamic-debug-howto.txt as well. The ability to dynamically switch on and off debug messages per callsite is extremely useful. And it also enables you to switch on some extra info you often want, like function names, without having to explictly put them into every format string. I recommend setting CONFIG_DYNAMIC_DEBUG and taking a look at /sys/kernel/debug/dynamic_debug/control if you ever do any kernel development. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Eudyptula Challenge Task 01
Jeff Haran writes: > Unless you happened to be consigned to using Outlook because your > employer's IT is all MS, through which it is impossible to send a > plain text email without it getting munged one way or another. emacs runs fine on Windows too, so using Gnus is always an option for the most hardcore GNU evangelists. And I am sure there are a number of other email clients which will do a good job even if they run on Windows systems. If your aren't allowed to run anything but Outlook, then you just have to teach your employer about the BYOD hype :-) Bjørn (who have been using OS/2, Windows, Solaris and Linux based desktop systems at work, but never moved away from Gnus as primary email client) ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: v3.15 kernel panic, bisecting didn't help
Greg Donald writes: > On Tue, Jun 10, 2014 at 4:29 AM, Bjørn Mork wrote: >> Greg Donald writes: >> >>> [0.00] Linux version 3.15.0-1+ (root@mars) (gcc version 4.7.2 >> >> What's with the '+'? Do you have some commit on top of v3.15? If so, >> did you include that in your bisect? > > The + is something Debian's make-kpkg adds. It always appears after > my --append-to-version value. > > I have no commits on this tree. Ah, OK. Just a tip: You can also create Debian kernel packages directly from a mainline kernel with "make deb-pkg" (optionally with -jx etc as usual). Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
