Re: [RFC PATCH] kvm: replace spaces with a tab

[Greg KH]

On Thu, May 16, 2024 at 10:31:45AM +0100, Mohamed Karaoui wrote:
> Hi list,
> 
> This is an attempt to get a feeling of sending a first patch. Please feel
> free to comment.
> 
> I have few questions:
> 
> - I have build this patch against the torvalds/linux.git. Does it matter
> which tree I use as long as it works on the maintainer tree?
> 
> - In this particular case I checked the maintainer. It seems that its
> tree is something of 11 years old.

I suggest working on drivers/staging/ first for basic coding style fixes
like this, as they are encouraged there, but not necessarily in other
parts of the kerenel at all.

Good luck!

greg k-h

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

Re: Adding a device support

[Greg KH]

On Thu, May 02, 2024 at 01:47:21PM +0200, Rémi ESSAISSI wrote:
> Hello
> 
> I bought without checking its support a USB->VGA/HDMI adapter.
> 
> the Fresco Logic FL2000  .
> 
> Some code is at https://github.com/FrescoLogic/FL2000 .
> 
> But unfortunately unusable as is.

Why not?

> I would like to know if there is anything I can do to help getting it fully
> supported .

Try forward-porting that driver and getting it to work?

have fun!

greg k-h

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

Re: Before submitting a driver for Casper Excalibur Laptops

[Greg KH]

On Wed, Feb 21, 2024 at 01:30:11AM +0300, Mustafa Ekşi wrote:
> 2. Where should I put my driver?
> staging/ or platform/x86/? I'm planning to extend my driver to support more
> laptops from the same vendor.

drivers/staging/ is only for code that is not ready to be merged and it
must have a TODO file that lists what needs to be done.  I'd recommend
just fixing the issues first and submitting it for drivers/platform/
directly.

> 3. Should I wait to extend support of the driver before submitting it?

No, send it now, no need to wait!

good luck!

greg k-h

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

Re: firefox does not start with 6.8-rc

[Greg KH]

On Sat, Feb 10, 2024 at 11:41:27AM +0100, Philipp Hortmann wrote:
> Hi,
> 
> compiled the latest staging kernel on my xubuntu laptop. It starts fine but
> I cannot start my firefox anymore. This happens only with kernel 6.8-rcx.
> With kernel 6.7 no issue at all. Find logs below. Found in some forum that
> it is fixed in some later rc on an other tree. Tried to find this patch
> series that fixes this. But was not able to.
> 
> But anyway is this a kernel issue? Do the kernel developers care?

Yes, but this looks like a self-inflicted issue:

> mr0@mr0-dell:~$ sudo dmesg -c
> [  281.781051] audit: type=1400 audit(1707558512.842:62): apparmor="DENIED"
> operation="capable" class="cap"
> profile="/snap/snapd/20671/usr/lib/snapd/snap-confine" pid=1566
> comm="snap-confine" capability=12  capname="net_admin"

apparmor is saying no here.  Perhaps you need to update your rules for
it?

thanks,

greg k-h

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

Re: Kernelnewbies

[Greg KH]

On Thu, Feb 08, 2024 at 03:11:33PM +, Turritopsis Dohrnii Teo En Ming wrote:
> Subject: Kernelnewbies
> 
> Good day from Singapore,
> 
> If we want to do kernel coding, what is the programming language that we must 
> know?

Take a look at the Linux kernel source code itself to see what is
needed, it all depends on what portion(s) you are modifying.

good luck!

greg k-h

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

Re: Generic USB LED HID driver

[Greg KH]

On Fri, Jan 19, 2024 at 12:45:52PM +0100, Kirill Yatsenko wrote:
> Hello Greg,
> 
> Thanks for the suggestions!
> Yes, it will be better to implement the communication from the userspace.
> 
> However, I was curious if the kernel implements some generic LED HID
> interface already,
> without the need to write custom code. Similarly, as it's done for example
> for the HID multitouch,
> where the device only needs to report the correct report descriptor.

I do not think there is a generic HID description yet, is there?  If so,
the kernel should support it, otherwise it is all vendor-specific stuff
that belongs in userspace.

thanks,

greg k-h

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

Re: Generic USB LED HID driver

[Greg KH]

On Fri, Jan 19, 2024 at 11:21:51AM +0100, Kirill Yatsenko wrote:
> Hello,
> 
> I'm trying to find the Linux kernel driver in the tree that implements the
> HID LED usage table.
> The only driver that I've found is the hid-led.c. However, it seems to
> support only specific devices.
> 
> The device with which I'm trying to interface is the custom-made board with
> atxmega and some LEDS connected to it.
> Currently, the communication is done through the vendor-specific HID
> protocol.
> The custom USB HID kernel module is implemented to communicate with the
> device.

Why not do this from userspace using libusb or the generic hid userspace
api?  Why do you need a kernel driver?

thanks,

greg k-h

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

Re: Identifying the initial bug within the x86 architecture subsystem

[Greg KH]

On Wed, Jan 03, 2024 at 03:23:13PM +0530, Dileep Sankhla wrote:
> On Wed, Jan 3, 2024 at 12:33 PM Greg KH  wrote:
> > What do you mean by "first bug"?  Why does the location in an
> > arbitrary list matter?
> 
> Hello Greg,
> 
> >From "first bug" I meant the initial bug for me to solve under this 
> >subsystem.
> 
> > Also, bugzilla is not used by many kernel subsystems, so perhaps the
> > items there just aren't relevant for this one either?
> 
> I looked for the bugs in the subsystem's mailing list but did not find
> anything beginning with the subject line "PROBLEM: ".

I have never seen a bug report for the kernel come in with that in the
subject line, sorry.  So that would be one reason why you might not find
anything.

And maybe there are no x86-specific bugs at the moment?  Try running
linux-next and see if you have any issues with any subsystem, if so, try
working on that.

good luck!

greg k-h

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

Re: Identifying the initial bug within the x86 architecture subsystem

[Greg KH]

On Wed, Jan 03, 2024 at 11:12:57AM +0530, Dileep Sankhla wrote:
> Last night, I dedicated time to go through bugs on Bugzilla (see [1]),
> considering their priorities but I could not figure out which one to
> pick. While I found only a couple of bugs with the latest modification
> date, I lack the same hardware as the original poster (OP) to
> reproduce and fix those bugs. How can I identify the first bug in this
> subsystem? Given the relatively low number of bugs, should I consider
> reaching out to the maintainer of `arch/x86/boot` if I cannot find a
> suitable one to fix?

What do you mean by "first bug"?  Why does the location in an
arbitrary list matter?

Also, bugzilla is not used by many kernel subsystems, so perhaps the
items there just aren't relevant for this one either?

good luck!

greg k-h

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

Re: ktypes vs. devices classes (struct class)

[Greg KH]

On Sun, Oct 01, 2023 at 11:15:12PM +0200, Richard wrote:
> > > I've seen struct class defines **class_groups, but (contrary to struct
> > > kobj_type) not the corresponding struct sysfs_ops, why? Where is it then?
> > 
> > groups are used to define attributes (i.e. sysfs files).  sysfs_ops is
> > much "lower" in the stack.
> > 
> > I think the description of how the driver model works in the book, Linux
> > Device Drivers, 3rd edition, free online, should still represent how
> > things work on this layer pretty well, although we have changed things
> > in places over time since the book was written.  Try looking that first.
> 
> I looked it up and my understanding is that those attributes are actually
> all embedded in instances of "struct class_attribute" and since they all
> bring their own store() and show() functions it's not necesarry to contain
> them in directly in "struct class". The whole mechanic with container_of()
> makes sure in the end the right "subroutine" gets called.
> 
> Is this correct?

Close enough, yes :)

The "fun" with attributes and sysfs files is a very tricky one, relying
entirely on the location of the callbacks in memory to match up properly
with some other structures and to pass around pointers like crazy.  It
has played havoc on some tools like CFI and will be very "interesting"
to see how it every works in languages other than C (i.e. rust.)

greg k-h

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

Re: ktypes vs. devices classes (struct class)

[Greg KH]

On Sun, Oct 01, 2023 at 11:50:46AM +0200, Greg KH wrote:
> On Sat, Sep 30, 2023 at 08:17:26PM +0200, Richard wrote:
> > Hi,
> > 
> > I appreciate your answer, thank you for your time.
> > 
> > > 
> > > Look closer.  Tell me what "struct class" is for vs. what "struct
> > > kobj_type" is for and see if they both could be used for the same thing?
> > 
> > I've looked at the definitions in include/linux and thought a bit about the
> > semantics.
> > 
> > struct kobj_type defines behaviour (sysfs_ops and default_attrs) that is
> > common for multiple kobjects. But those kobjects could be embedded in
> > drivers, devices or a bus.
> > 
> > I think one core difference is that "struct class" is strictly for devices
> > so it's more specific and contains a lot of members that are only relevant
> > for devices.
> 
> Close.
> 
> "struct class" represents how userspace interacts with a device (tty /
> input / block / etc.)
> 
> "struct kobj_type" is needed to describe what "type" of struct kobject a
> specific kobject is.  It defines a number of operations that handle the
> lifespan of the kobject.
> 
> > My digging however has brought me to a few new questions:
> > 
> > Do all devices (their kobjects to be more precise) in one class (e.g.
> > /sys/class/net ) belong to the same ktype?
> 
> ktype is "lower" than classes.  ktype is not used for things in the
> driver model, it's used for things "lower" than the driver model (and to
> implement the driver model itself.)
> 
> So no driver should ever be messing with a ktype.  If you want to have a
> different "type" of device on the same bus or class, use "struct
> device_type" as that's what that is for.
> 
> > Is it possible that one device belongs to several classes?
> 
> No.

Oops, well yes.  Depends on what you are thinking is a "device" here.

In the kernel, yes, a 'struct device' on a bus can then register itself
with multiple subsystems that handle different classes, and then
individual 'struct device' are created for those classes that have a
parent of the original 'struct device' on the bus.

But within a 'struct class', there can only be one "struct device" for
that class for that specific class type (we used to call them "struct
class_device" but that got removed a long time ago as the objects really
all did the same thing.)

It's a bit confusing, yes, sorry, but creating a unified object model of
all devices in the system turns out to be complex due to the huge range
of devices that an operating system needs to manage, which is probably
why most other operating systems have never attempted to do such a
thing.

When Pat and I created it, we were young and naive and thought "this
should be simple!"  Famous last words...

thanks,

greg k-h

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

Re: ktypes vs. devices classes (struct class)

[Greg KH]

On Sat, Sep 30, 2023 at 08:17:26PM +0200, Richard wrote:
> Hi,
> 
> I appreciate your answer, thank you for your time.
> 
> > 
> > Look closer.  Tell me what "struct class" is for vs. what "struct
> > kobj_type" is for and see if they both could be used for the same thing?
> 
> I've looked at the definitions in include/linux and thought a bit about the
> semantics.
> 
> struct kobj_type defines behaviour (sysfs_ops and default_attrs) that is
> common for multiple kobjects. But those kobjects could be embedded in
> drivers, devices or a bus.
> 
> I think one core difference is that "struct class" is strictly for devices
> so it's more specific and contains a lot of members that are only relevant
> for devices.

Close.

"struct class" represents how userspace interacts with a device (tty /
input / block / etc.)

"struct kobj_type" is needed to describe what "type" of struct kobject a
specific kobject is.  It defines a number of operations that handle the
lifespan of the kobject.

> My digging however has brought me to a few new questions:
> 
> Do all devices (their kobjects to be more precise) in one class (e.g.
> /sys/class/net ) belong to the same ktype?

ktype is "lower" than classes.  ktype is not used for things in the
driver model, it's used for things "lower" than the driver model (and to
implement the driver model itself.)

So no driver should ever be messing with a ktype.  If you want to have a
different "type" of device on the same bus or class, use "struct
device_type" as that's what that is for.

> Is it possible that one device belongs to several classes?

No.

> I've seen struct class defines **class_groups, but (contrary to struct
> kobj_type) not the corresponding struct sysfs_ops, why? Where is it then?

groups are used to define attributes (i.e. sysfs files).  sysfs_ops is
much "lower" in the stack.

I think the description of how the driver model works in the book, Linux
Device Drivers, 3rd edition, free online, should still represent how
things work on this layer pretty well, although we have changed things
in places over time since the book was written.  Try looking that first.

> > When we implemented them, we didn't think so but maybe something has
> > changed to now allow this?  If so, great, please send us patches to do
> > so!
> 
> Oh please don't misunderstand me, even if we had come to an agreement that
> this architecture was unelegent (which it isn't I see the point now), I
> don't think that would have been reason enough to change it.

Change is good if it is needed, that's how code evolves, based on new
ideas and use cases.  So that's fine if needed.

hope this helps,

greg k-h

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

Re: ktypes vs. devices classes (struct class)

[Greg KH]

On Sat, Sep 30, 2023 at 02:12:41AM +0200, Richard wrote:
> Hi all,
> 
> Why do we have ktypes (struct kobj_type) AND device classes (struct class)?

Because they are two totally different things.

> Don't they serve the same purpose (more or less) and it would be simpler,
> clearer and more KISS to only have one? Is this a historically grown thing
> or by design?

Look closer.  Tell me what "struct class" is for vs. what "struct
kobj_type" is for and see if they both could be used for the same thing?

When we implemented them, we didn't think so but maybe something has
changed to now allow this?  If so, great, please send us patches to do
so!

thanks,

greg k-h

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

Re: Kernel freeze down while booting

[Greg KH]

On Fri, Sep 22, 2023 at 12:10:00PM +, Christian Stalp wrote:
> BR Chris
> Confidentiality Notice: This message (including attachments) is a private 
> communication solely for use of the intended recipient(s). If you are not the 
> intended recipient(s) or believe you received this message in error, notify 
> the sender immediately and then delete this message. Any other use, 
> retention, dissemination or copying is prohibited and may be a violation of 
> law, including the Electronic Communication Privacy Act of 1986.   

Now deleted.

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

Re: Neomutt/mutt copy message-id with b4

[Greg KH]

On Mon, Jul 31, 2023 at 09:44:48AM +0200, Maciej Wieczór-Retman wrote:
> Hi!
> I was thinking on how to make using Neomutt 
> easier with b4 to apply patches for testing. 
> 
> In thunderbird there is an extension
> that creates a button, that copies the message id.
> This way I was able to paste that message-id into 
> b4, and apply a whole patch series to my kernel 
> source quickly. 
> 
> In neomutt I have the message-id in the header 
> field and I can copy it with the mouse but 
> I was curious if anyone found a nice 
> macro with a keybind to just copy the 
> message-id directly to clipboard?
> 
> Googling didn't give me any results, and neither
> did looking through mail archives.

For mutt I use:
macro index B |'b4 am -t -o - | git am -s'\n

which binds the key "B" to take the current message and pass it through
to b4 to apply the whole patch series to the tree in the local
directory.

hope this helps,

greg k-h

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

Re: kernel modules, derived work and GPLv2

[Greg KH]

On Wed, Jul 12, 2023 at 03:56:40PM +0100, Phil Perry wrote:
> Hello list,
> 
> I am seeking to fully understand my obligations under the GPL regarding
> kernel modules, derived works and requirements to distribute the source
> code.

Wonderful.  Please contact a lawyer about this if you have questions
about this type of thing, as they are the only ones that can give you
legal advice.

Best of luck!

greg k-h

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

Re: Getting help in writing tty driver

[Greg KH]

On Fri, Jul 07, 2023 at 04:37:53PM +0530, Ayush Singh wrote:
> Hello everyone, I am working on a Google Summer of Code 2023 project [1]
> under BeagleBoard.or. In this project, I have to write a Linux driver that
> exposes `dev/ttyMCU0` (or something else) which can be accessed as a Serial
> tty by MCUmgr [2]. This then sends the data and gets the response from the
> CC1352 processor in BeagelPlay [3], which runs Zephyr over HDLC UART (the
> data for this tty port has a particular HDLC address).
> 
> However, all the resources I could find seem to use deprecated or old APIs
> (like `alloc_tty_driver` instead of `tty_alloc_driver`). After some trial
> and error, I was able to transfer the data written to `ttyMCU0` to CC1352
> using `write` in `tty_operations`. However, I am stumped on how to send
> data to tty from the driver so that the userspace application can read it
> (like using `cat`). Supposedly it should be done using
> `tty_insert_flip_char` but the signature for this function in the tutorials
> and the one present at `tty_flip.h` is quite different and does not seem to
> work for me. Also, there seems to be something about the Echo flag but not
> sure what all that is.
> 
> Finally, I am not sure I understand the relationship between tty port, tty
> device, and tty driver either so it would be great if someone can guide me
> to resources related to tty. I think a simple tty echo driver should allow
> me to get the hang of what I am supposed to do.

Try looking at the tty driver example in the book, "Linux Device
Drivers, third edition".  It's out of date, but the ideas a much the
same in places for tty drivers.  And then look at any of the hundreds of
in-kernel tty drivers for examples of what to do.  You might want to
look at the "smaller" ones as you don't want to get bogged down with the
uart-specific stuff.

good luck!

greg k-h

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

Re: Kernel module for a network interface - remove trailer from sk_buff on reception

[Greg KH]

On Fri, Jun 30, 2023 at 07:16:11AM +0530, Abhiram V wrote:
> Yeah, I did ask for help in the college itself. Unfortunately, no one has
> any experience with the kernel. They don't mind getting help from the
> community.
> 
> It was for my final year project and the grades have already been assigned
> with whatever I have done so far. The work was accepted for a conference; I
> wanted to fix this issue before I present it there. I'll be sure to
> acknowledge the help I have got from here.
> 
> The only part that isn't working is the removal of the RCT. I did try to
> get it to work on my own. But I got stuck and don't know what I'm doing
> wrong. So I came here for some help, to know what I'm doing wrong.

Best is to post your code to the netdev mailing list, they will be able
to help you there.  Without code it's very hard to discuss technical
specifics.

good luck!

greg k-h

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

Re: Kernel module for a network interface - remove trailer from sk_buff on reception

[Greg KH]

On Wed, Jun 28, 2023 at 04:15:36PM +0530, Abhiram V wrote:
> I am implementing the Parallel Redundancy Protocol (PRP, IEC standard
> 62439-3) as a kernel module for a school project of mine.

Asking for help on homework on public mailing lists is generally frowned
apon as we are not getting the grade here, you are.

Is your professor ok with asking the community for help with this?

thanks,

greg k-h

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

Re: PCie card information for ACPI and Device Tree systems

[Greg KH]

On Sat, Jun 17, 2023 at 10:20:01AM +0100, Lucas Tanure wrote:
> Hi,
> 
> How can the kernel read hardware information for a PCIe card if ACPI
> in the BIOS doesn't have it?
> The DSDT/ACPI information doesn't contain information about an
> external PCIe inserted in the motherboard, so how can the Kenerl
> discover its hardware information?

The PCI bus protocol has a function to walk the devices and let the host
operating system know a device is present and then the operating system
does the device probe and reads the hardware information from the device
itself.

> If the kernel has the rule of not hardcoding hardware information in
> its driver, what is the method to get hardware information for a PCIe
> not part of the motherboard?

Because that's not how PCI works :)

> And the same question for ARM device trees. How can the driver find
> hardware information about a PCIe card that is not in the loaded DTB
> for the system?

PCI is CPU agnostic.

Just like USB and other self-discoverable busses.

See the PCI specification for more details if you are curious, there are
some good books out there on how this works at the low level if you want
to know more.

hope this helps,

greg k-h

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

Re: Starting to learn Linux...

[Greg KH]

On Fri, May 19, 2023 at 01:24:18PM +0530, Deepak Goel wrote:
> This link is good. However it is listing all the software which runs on
> Linux-kernel. I want to know what's going on inside the Linux-kernel
> (thread management, memory management, interface to devices, etc).

What of the many free books and other online resources have you read
that did not cover this well already?  Specific questions are best, and
also, you have access to the whole source code of Linux, have you tried
reading that and just following the basic code flows of something
"simple" to understand this type of thing?

thanks,

greg k-h

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

Re: API between modules

[Greg KH]

On Thu, May 18, 2023 at 08:16:18AM +0100, Lucas Tanure wrote:
> Hi,
> 
> I have two kernel modules that need to talk over an API, and right
> now, they are statically linked together, but I am looking for a
> better way to separate them and share an API between them.
> 
> A few years ago, I did the HDA component:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/sound/pci/hda/hda_component.h
> 
> Using the component API:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/include/linux/component.h
> 
> Are there other ways for a module to wait for another module to load
> and use its API?
> Is there a default way to do that?

Yes, just call a function in that other module and it will be loaded
properly before your module can call it.  That's how all in-kernel apis
work.

thanks,

greg k-h

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

Re: Build mainline driver for another Kernel Version

[Greg KH]

On Wed, May 17, 2023 at 09:47:21AM +0100, Lucas Tanure wrote:
> On Wed, May 17, 2023 at 9:22 AM Greg KH  wrote:
> >
> > On Wed, May 17, 2023 at 09:16:45AM +0100, Lucas Tanure wrote:
> > > Hi,
> > >
> > > Can I build a driver in the mainline kernel to a previous kernel version?
> >
> > Not easily, and you really do not want to do that as the whole kernel
> > source, drivers included, are a snapshot in time and depend on each
> > other.
> >
> > > Like, in the mainline kernel, I have a Z driver, and I want to use
> > > that driver for my current stable driver in my embedded system with
> > > version kernel 5.15. Is there a procedure to build a kernel driver
> > > against other specific kernel headers?
> >
> > Update to a newer kernel version, it will be much easier and simpler
> > overall.
> >
> > Drivers consume _everything_ from the core kernel, and are not
> > stand-alone at all.  They depend on everything else, trying to pick one
> > out and put it into a different kernel is not how Linux works at all,
> > sorry.
> >
> > What prevents you from just using a newer kernel?
> >
> > thanks,
> >
> > greg k-h
> 
> It's not me or my team; it's every client for the company I work for
> that uses different kernel versions.

Then get the driver code merged upstream so that it is present in all
kernel versions.

> And I am investigating how we can upstream our driver in the future
> and provide our driver to all customers having to support many
> different kernel versions.

Yes, that is the correct solution.

> I think the only way is to have a few kernel branches with different
> kernel versions, but our driver is updated in those branches.
> Any better idea?

Get your code upstream :)


You can create a stand-alone driver, that attempts to work for all
kernel versions (or a limited set of versions), with proper use of
macros and #ifdef in .h files.  But it's a lot of work and energy and
waste of time.  It's cheaper and faster overall to get your code merged
upstream so you don't have to do any of that at all, as that is the
proper solution for what Linux expects.

And again, it saves you money, which is a good thing to tell your
manager.

thanks,

greg k-h

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

Re: Build mainline driver for another Kernel Version

[Greg KH]

On Wed, May 17, 2023 at 09:16:45AM +0100, Lucas Tanure wrote:
> Hi,
> 
> Can I build a driver in the mainline kernel to a previous kernel version?

Not easily, and you really do not want to do that as the whole kernel
source, drivers included, are a snapshot in time and depend on each
other.

> Like, in the mainline kernel, I have a Z driver, and I want to use
> that driver for my current stable driver in my embedded system with
> version kernel 5.15. Is there a procedure to build a kernel driver
> against other specific kernel headers?

Update to a newer kernel version, it will be much easier and simpler
overall.

Drivers consume _everything_ from the core kernel, and are not
stand-alone at all.  They depend on everything else, trying to pick one
out and put it into a different kernel is not how Linux works at all,
sorry.

What prevents you from just using a newer kernel?

thanks,

greg k-h

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

Re: Starting to learn Linux...

[Greg KH]

On Wed, May 17, 2023 at 10:57:23AM +0530, Deepak Goel wrote:
> Now my second question is, how do I develop a small kernel from scratch by
> myself. Very simple one initially for Arduino Uno. Is it possible?

Yes, it is possible, but that's outside of this mailing list's topic.
There are many great answers for how to do this online, good luck!

greg k-h

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

Re: screening patch here before sending to devs

[Greg KH]

On Tue, Mar 28, 2023 at 12:47:26AM -0700, Daniel Watson wrote:
> i would like to work on my laptop battery's charge threshold. it can be
> changed in the bios, but not while running. there's a project for doing
> this on some thinkpads, but not the framework laptop. any pointers for
> where to get more info about this would be greatly appreciated.

Are you sure that it is even possible to change this from the operating
system while the system is running?  It might be restricted only to the
BIOS settings.

thanks,

greg k-h

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

Re: Query on New LTS version

[Greg KH]

On Mon, Jan 23, 2023 at 11:35:37AM +0530, Arun Sudhilal wrote:
> Hi,
> 
> What is the latest LTS version?
> 
> https://www.kernel.org/category/releases.html
> 
> The above page still says it is 5.15.
> 
> https://lwn.net/Articles/915435/
> But the above lwn page says 6.1 is 2022 LTS.
> 
> kernel.org link is no more updated?

Please see the thread at:
  
https://lore.kernel.org/all/CAPDLWs-Z8pYkwQ13dEgHXqSCjiq4xVnjuAXTy26H3=8nzcp...@mail.gmail.com

for details and help answer the questions provided there.

thanks,

greg k-h

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

Re: 2 modules from 1 source ?

[Greg KH]

On Mon, Dec 19, 2022 at 10:02:42AM -0700, jim.cro...@gmail.com wrote:
> On Mon, Dec 19, 2022 at 9:37 AM  wrote:
> >
> > Id like to build 2 modules (with different names)
> > from a single source file, with 2nd being dependent
> > on the 1st.
> >
> > Specifically, Ive got:
> > lib/test_dynamic_debug.c
> >
> > I want
> > A:  lib/test_dynamic_debug.ko
> > B:  lib/test_dynamic_debug_submod.ko
> >
> > I expect that the code just needs an #ifdef #else #endif
> > block to clearly put the dependor & dependee elements
> > next to each other.
> >
> > My question is how to do this in the Makefile ?
> > this does most of it
> >
> > --- a/lib/Makefile
> > +++ b/lib/Makefile
> > @@ -78,7 +78,8 @@ obj-$(CONFIG_TEST_SORT) += test_sort.o
> >  obj-$(CONFIG_TEST_USER_COPY) += test_user_copy.o
> >  obj-$(CONFIG_TEST_STATIC_KEYS) += test_static_keys.o
> >  obj-$(CONFIG_TEST_STATIC_KEYS) += test_static_key_base.o
> > -obj-$(CONFIG_TEST_DYNAMIC_DEBUG) += test_dynamic_debug.o
> > +obj-$(CONFIG_TEST_DYNAMIC_DEBUG) += test_dynamic_debug.o
> > test_dynamic_debug_submod.o
> > +CFLAGS_test_dynamic_debug_submod.o += -DTEST_DYNAMIC_DEBUG_SUBMOD
> >  obj-$(CONFIG_TEST_PRINTF) += test_printf.o
> >
> > but how do I tell it the 2nd target ?
> 
> more to the point, this doesnt work (nor do permutations), I miss something:
> 
> +($obj)/test_dynamic_debug_submod.o: ($obj)/test_dynamic_debug.c

Pleaase don't do that :(

If you _REALLY_ need to do this, then just #include your .c file into
two other .c files.  And keep everything in your #included .c file
static to make sure you don't have duplicate global symbols.

Otherwise it is impossible for the same .o to be linked into two
different modules (or into the kernel image itself) as there will be
duplicate global symbols (as that .c file had to have something global
for you to be able to call into it.)

But step back, what is the problem that you really want to solve here
that you feel somehow a single .c file built twice would be correct?
Especially with code in lib/ that should not be needed at all as you are
building "library" functions that only get included if they are actually
used in the large kernel image.

thanks,

greg k-h

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

Re: large global static arrays

[Greg KH]

On Thu, Dec 15, 2022 at 12:01:37PM +0530, Ani Sinha wrote:
> On Thu, Dec 15, 2022 at 11:59 AM Greg KH  wrote:
> >
> > On Thu, Dec 15, 2022 at 11:44:32AM +0530, Ani Sinha wrote:
> > > Hi
> > >
> > > I’m curious to know whether large static arrays can be declared inside
> > > any module ( kernel source .c file).
> >
> > Yes.
> >
> > > I am aware that kernel stack
> > > space can be limited and so within the function it’s not a good idea
> > > to declare large sized arrays. I’m just wondering if the same
> > > restriction applies to global declaration of arrays.
> >
> > As they are not on the stack, they are fine.  See the kernel source for
> > lots of examples of this.
> 
> Can you point me to one?

You can search the source tree as easily as I can, so I'll leave it as
an "exercise for the reader" to complete :)

have fun!

greg k-h

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

Re: large global static arrays

[Greg KH]

On Thu, Dec 15, 2022 at 11:44:32AM +0530, Ani Sinha wrote:
> Hi
> 
> I’m curious to know whether large static arrays can be declared inside
> any module ( kernel source .c file).

Yes.

> I am aware that kernel stack
> space can be limited and so within the function it’s not a good idea
> to declare large sized arrays. I’m just wondering if the same
> restriction applies to global declaration of arrays.

As they are not on the stack, they are fine.  See the kernel source for
lots of examples of this.

greg k-h

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

Re: OBJTOOL Build error

['Greg KH']

On Thu, Dec 01, 2022 at 10:52:16AM -0500, John Aron wrote:
> On Wed, Nov 30, 2022 at 06:36:19PM -0500, John Aron wrote:
> > One C file and a few header files.
> 
> Can you provide a link to them so that we can see what might be the problem?
> Without that, it's impossible to help, sorry.
> --
> The repo is in a private repo online, the entry is:
> static int __init kernel_module_start(void)



Without the full source, it's pretty impossible to help, sorry.

thanks,

greg k-h

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

Re: OBJTOOL Build error

[Greg KH]

A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

On Wed, Nov 30, 2022 at 06:36:19PM -0500, John Aron wrote:
> One C file and a few header files.

Can you provide a link to them so that we can see what might be the
problem?  Without that, it's impossible to help, sorry.

thanks,

greg k-h

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

Re: struct definition inside a function

[Greg KH]

On Tue, Nov 29, 2022 at 03:06:30PM +, Anuz Pratap Singh Tomar wrote:
> Hi all,
> I have not seen a struct define inside a function in kernel code and
> couldn't find any guidelines if it's permitted or frowned upon?
> 
> int fn(int i)
> {
>  struct my_struct {
> int var1;
> int var2
> }; /* is this allowed? */
> struct my_struct struct_local;

Yes, it is allowed, but usually you never want to do that in a kernel
function as structures are normally used across functions, not just only
in a single one.

Do you have a real-world example where you feel this pattern is the
best?

thanks,

greg k-h

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

Re: OBJTOOL Build error

[Greg KH]

On Thu, Nov 24, 2022 at 01:48:08PM -0500, John Aron wrote:
> Hello -
> 
>  
> 
> I have an idea of where to begin: our kernel code compiles and works on Red
> Hat, CentOS, and Fedora. In Ubuntu 20.04, I have an error.
> 
>  
> 
> root@form:/home/john/thor-linux/Kernel/ubuntu20.04# make
> 
> rmmod: ERROR: Module thor is not currently loaded
> 
> make: [Makefile:7: all] Error 1 (ignored)
> 
> make[1]: Entering directory '/usr/src/linux-headers-5.4.0-131-generic'
> 
>   CC [M]  /home/john/thor-linux/Kernel/ubuntu22.04/thor.o
> 
> /home/john/thor-linux/Kernel/ubuntu22.04/thor.o: warning: objtool:
> _Controller_process_response_map()+0x1b3:unreachable instruction
> 
>   Building modules, stage 2.
> 
>   MODPOST 1 modules
> 
>   CC [M]  /home/john/thor-linux/Kernel/ubuntu22.04/thor.mod.o
> 
>   LD [M]  /home/john/thor-linux/Kernel/ubuntu22.04/thor.ko
> 
> make[1]: Leaving directory '/usr/src/linux-headers-5.4.0-131-generic'
> 
> make[1]: Entering directory '/usr/src/linux-headers-5.4.0-131-generic'
> 
>   CLEAN   /home/john/thor-linux/Kernel/ubuntu22.04/Module.symvers
> 
> make[1]: Leaving directory '/usr/src/linux-headers-5.4.0-131-generic'
> 
> #@sudo dmesg -C
> 
> #@sudo insmod /usr/local/etc/thor.ko
> 
> filename:   /usr/local/etc/thor.ko
> 
> version:0.1
> 
> description:THOR KMOD
> 
> author: Aronetics
> 
> license:GPL
> 
> srcversion: BC856FA85DB2FEFD38A1B2A
> 
> depends:
> 
> retpoline:  Y
> 
> name:   thor
> 
> vermagic:   5.4.0-131-generic SMP mod_unload modversions
> 
> #@sudo dmesg
> 
> root@form:/home/john/thor-linux/Kernel/ubuntu20.04#
>  
> 
>  
> 
> Every 2.0s: tail -n30 /var/lib/dkms/thor/1.0.1/build/make.log
> 
>  
> 
> DKMS make.log for thor-1.0.1 for kernel 5.4.0-131-generic (x86_64)
> 
> Thu 24 Nov 2022 01:10:33 PM EST
> 
> make: Entering directory '/usr/src/linux-headers-5.4.0-131-generic'
> 
>   CC [M]  /var/lib/dkms/thor/1.0.1/build/thor.o
> 
> /var/lib/dkms/thor/1.0.1/build/thor.o: warning: objtool:
> _Controller_process_response_map()+0x1b3: unreachable instruction
> 
>   Building modules, stage 2.
> 
>   MODPOST 1 modules
> 
>   CC [M]  /var/lib/dkms/thor/1.0.1/build/thor.mod.o
> 
>   LD [M]  /var/lib/dkms/thor/1.0.1/build/thor.ko
> 
> make: Leaving directory '/usr/src/linux-headers-5.4.0-131-generic'
> 
>  
> 
> Is this an error in objtool on Ubuntu within
> /usr/src/linux-headers-5.4.0-${26-130}/tools/objtool ?

Do you have a pointer to your code anywhere?  Do you have .S files in
it, or is it all C files?

And did you ask the Canonical developers about this?  You should have a
support contract you are paying for with them, so why not use that?

thanks,

greg k-h

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

Re: Source code organization

[Greg KH]

On Fri, Oct 21, 2022 at 01:51:48AM +, Billie Alsup (balsup) wrote:
> 
> > From: Greg KH 
> >    - is this something else?  Then pick a place and submit a patch
> >  and people will tell you if you got it wrong :)
> 
> I think this is going to be my strategy, except per a separate recommendation,
> I will put it in drivers/platform/cisco, similar to the existing chrome, 
> goldfish,
> mellanox, and surface already under drivers/platform.  These drivers really
> are Cisco hardware specific, so I'd like to keep them grouped together,
> if reviewers will allow it!

Platform drivers are the "catch all" for where you have to talk to tiny
hardware-specific devices.  That's normally not an i2c controller.

> > But step back, why are you creating MFD devices anyway?  Why not make
> > "real" devices in your hardware representation as you control the FPGA
> > and DT definitions, right?
> 
> Currently the FPGAs themselves are discovered (for pci bus), or explicitly
> instantiated (for i2c, whether via user mode script, device tree, or
> ACPI configuration).

So you are creating platform devices for a dynamic device that is on
another bus?  Please no, that is an abuse of the platform device code.
That's the biggest reason NOT to use MFD for your code.

Just make normal drivers for these, no need for MFD at all, why do you
want to use that api here?

> The slpc and p2pm MFD drivers also "discover"
> the peer FPGA. Are you suggesting that I create a new bus driver
> for a Cisco FPGA?

If it is a bus, then yes, you should.  That's a very simple thing to do.

> I was under the impression that the MFD framework was explicitly meant
> for this type of application.

Nope!  But it has been abused for situations like this.  there are
simpler ways to do this now, including the auxiliary bus code, which
might be what you need to use here instead.

> I do dynamically
> create the array of struct mfd_cell passed to devm_mfd_add_devices
> (versus having an fpga specific driver), which achieves the same 
> purpose as a bus driver (I think).

Close, but you are making fake platform devices for a dynamic discovered
device, which is not ok.  Please use a real bus for this, either your
own, or the aux bus code.

> It's just that I thought MFD framework
> was meant for this type of application, and that's what I went with.
> The drivers themselves have been written over the last several years
> (starting with use in ONIE and SONiC, and now being used with FBOSS).  It
> is only now that I have been authorized to make the source public.  Changing
> to a bus driver top layer would seem to be a very big change.  There
> are 30 or so drivers being used today with Cisco FPGAs, and
> that number will only grow over time.

Changing the bus layer should not be a big deal, and just because the
code is old doesn't mean it has to be fixed up properly to get it merged
into the tree.  That's the best reason for why it needs to be fixed up,
you shouldn't be using apis and interfaces that are not designed for
what you are doing :)

Do you have a pointer to the source for these?  That might make it
easier to discuss than general concepts here.

thanks,

greg k-h

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

Re: Source code organization

[Greg KH]

On Mon, Oct 17, 2022 at 06:00:40PM +, Billie Alsup (balsup) wrote:
> I have a set of drivers that I would like to upstream.  These are primarily
> MFD style drivers supporting Cisco-8000 FPGAs.  The devices can be
> instantiated through multiple top level drivers, which provide the access
> mechanism for the MFD driver.  For example, an FPGA can be accessed via
> PCI, or via i2c, or via SLPC, or via P2PM (a point-to-point interface).  We
> currently build these drivers out of tree, under a single directory 
> drivers/cisco.
> I note that existing drivers are spread out across the kernel tree, sometimes
> by bus (pci, i2c), sometimes by function (gpio, net/mdio, spi), and sometimes
> under the generic mfd.

Yes, it's not always easy to find the common pattern, but usually it is:
- is this a bus driver that allows bus access to this hardware
  (pci, gpio, i2c)?  If so, add to drivers/pci|gpio|i2c
- is this a userspace-facing driver that implements a user
  "class" of interactions (input, HID, block, etc.).  If so, add
  to drivers/input|hid|block
- is this something else?  Then pick a place and submit a patch
  and people will tell you if you got it wrong :)

> I would like to start the upstream review process for our drivers, but first 
> want
> to get recommendations on the source code layout.  Is it permissible to keep
> a top level directory such as drivers/cisco to organize our code?  It is not 
> only
> the source code that is affected, but also provides a central place for 
> Kconfig
> entries.  Our FPGAs have multiple logical blocks, each of which is handled by
> a different MFD driver, e.g. i2c controllers, gpio controllers, spi 
> controllers, mdio
> controllers.  There can be multiple instances of each block as well (so 
> multiple
> MFD devices are instantiated for each driver).  And of course, there can be
> multiple FPGAs in a system, each with different combinations of logical 
> blocks.  
> 
> The drivers themselves are pretty specific to our FPGAs, thus it makes sense 
> to
> use Kconfig to select a hardware platform to automatically select the set of 
> MFD
> drivers (and top level bus drivers) that would apply. 
> 
> Would a source layout putting all the code under drivers/cisco be acceptable 
> in
> this case, or do I need to move things around and spread out the Kconfig 
> entries
> across directories? I note that a single drivers/cisco would simplify any 
> related
> modifications to MAINTAINERS as well.

No, we do not have "vendor" directories like this, as that's almost
always not what you want over time anyway.  Just scatter your drivers
around the tree based on the type and the subsystem interactions you
need to have.

But step back, why are you creating MFD devices anyway?  Why not make
"real" devices in your hardware representation as you control the FPGA
and DT definitions, right?  That would make things much easier if you
put the devices on a discoverable bus then the drivers can be autoloaded
as needed by the kernel when they are discovered.

Do that, then you can put your fpga interface in drivers/fpga :)

thanks,

greg k-h

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

Re: How to refer to a code snippet in email?

[Greg KH]

On Mon, Oct 10, 2022 at 05:55:33PM -0400, Drake Talley wrote:
> There is ample documentation for how to include a patch file, commits, or 
> diff in emails,
> but I haven't been able to discern what is the preferred way to refer to code 
> snippets
> as line ranges in a file for a given revision.
> 
> Is this just not that common so it isn't done?  Or is there a general approach
> to just pasting in a hunk of source code and manually stating the file/line 
> numbers?

It is not that common, but if needed, just copy the needed code into the
email and go from there.  We all work from different trees, so line
numbers do not usually match up, but function names should be enough to
orient people.

> Curious both as to what's possible in an email-driven git workflow and how 
> things are done here.

Again, it's not that common, look at the linux-kernel mailing list
archives on lore.kernel.org for examples of how things normally work.

good luck!

greg k-h

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

Re: Where do I put my new driver?

[Greg KH]

On Wed, Sep 21, 2022 at 04:26:29PM -0600, jim.cro...@gmail.com wrote:
> the path of least resistance might be to just put it in staging.

drivers/staging/ is not a dumping ground for drivers under active
development.  Just take the time and get it merged properly in the first
place, it's always faster and simpler that way.

thanks,

greg k-h

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

Re: how to debug... program hangs while downing for write a rwsem

[Greg KH]

On Wed, Sep 21, 2022 at 08:02:50PM +0900, Chan Kim wrote:
> Hello kernel experts and users,
> 
> I'm trying to boot linux-5.10.0-rc5 on our arm64 board (using neoverse-v1
> core).

5.10-rc5 is very very very old and obsolete, and not even a real
release.  Why are you using that specific kernel version?

At the very least, use a released and supported 5.10.y tree, but even
better, use the latest 5.19.y release.

> After the shell comes up, when I press enter key at the prompt, it gives me
> another prompt.
> But when I press enter key again, it stops responding.
> After inspecting where the program hangs, I found it hangs in function
> tty_set_termios while downing the rwsem.
> Please see below where I marked "<= this line "". (in file
> drivers/tty/tty_ioctl.c)
> 
> int tty_set_termios(struct tty_struct *tty, struct ktermios *new_termios)
> {
> struct ktermios old_termios;
> struct tty_ldisc *ld;
> 
> WARN_ON(tty->driver->type == TTY_DRIVER_TYPE_PTY &&
> tty->driver->subtype == PTY_TYPE_MASTER);
> /*
>  *  Perform the actual termios internal changes under lock.
>  */
> 
> 
> /* FIXME: we need to decide on some locking/ordering semantics
>for the set_termios notification eventually */
> down_write(>termios_rwsem);<== this
> line

What serial driver are you using that is causing this problem?

thanks,

greg k-h

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

Re: How to resubmit patches in the right way after review fixes?

[Greg KH]

On Sat, Aug 13, 2022 at 01:39:45AM +0300, Adverg Ebashinskii wrote:
> In case I have submitted a patch and some mistakes were pointed what is the
> right way of submitting a corrected version?
> I basically have 2 questions related to patch re-submit.
>  
> 1.  Is it appropriate to submit a new patch starting a new thread or it's
> required to reply
>     to one of the message in the old patch's thread to preserve a reference to
> the old one?

New thread is usually fine, but if you want you can do it in the old
thread, your choice.

> 2. In case the discussion of the patch ended up in patch redesign is it
> required to put a version when resubmitting?

Yes.

> For example the initial patch was [PATCH] sub/sys: summary. Should v2 be 
> placed
> in the description of the new patch like
> [PATCH v2] sub/sys: completely different summary due to redesign?

Yes.  And properly document your changes below the --- line as the
documentation asks for.

hope this helps,

greg k-h

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

Re: What is the right thing to do if a patch got ignored?

[Greg KH]

On Sun, Aug 07, 2022 at 11:05:39PM +0300, Adverg Ebashinskii wrote:
> What is the right things to do if a patch got ignored? Is it appropriate to
> request a feedback by explicitly replying to the thread or ignoring the patch
> automatically means that it was rejected? If it's possible to request a
> feedback how long should I before doing that? I'd like to request a feedback 
> to
> understand what was wrong about the patch to not do the same mistake when
> submitting a patch next time.

Wait a few weeks and then repost, patches get lost, resending is not a
big issue.

good luck!

greg k-h

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

Re: When reviewers stop responding

[Greg KH]

On Wed, Jun 22, 2022 at 06:20:04AM +0200, Philipp Hortmann wrote:
> On 6/7/22 19:23, Greg KH wrote:
> > And again, please help review code, otherwise you are just asking others
> > to do work for you, which if you think about it, could be construed as a
> > bit selfish, and I don't think you mean it to be.
> 
> Hi Greg,
> 
> this applies to me. I promise to improve. But this topic is not enough
> advertised. Everywhere information about patches can be found. But how to do
> a correct Reviewed-by: or Tested-by: is not so good documented.
> 
> I bought hardware to improve and did one "Tested-by:" of the patch:
> 
> [PATCH v2 0/5] Fixed some coding style issues and spelling
> from Chang Yu 
> 
> https://lore.kernel.org/linux-staging/91c9a0de-76f8-37fb-31b4-4401a6e35...@gmail.com/T/#t
> 
> Did I do something wrong or was I just unlucky?
> 
> Is 24 hours quick enough response?

Sometimes, yes, it is.  Other times I get to patches quicker than that
as I batch them up and process them once or twice a week.  You just got
unlucky and reviewed it after I had applied the changes, but that was
not the case for your other series you reviewed today.

thanks for the review, it's always appreciated.

greg k-h

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

Re: What to do when your patch gets ignored

[Greg KH]

On Fri, Jun 10, 2022 at 02:52:22PM +0200, Andrea Tomassetti wrote:
> The contents of this email are confidential. If the reader of this 
> message is not the intended recipient, you are hereby notified that any 
> dissemination, distribution or copying of this communication is strictly 
> prohibited. If you have received this communication in error, please notify 
> us immediately by replying to this message and deleting it from your 
> computer. Thank you. Devo, Inc; a...@devo.com ; 

Now deleted.

Note, this footer requires kernel developers to delete any email sent
with it as it is not compatible with the kernel license at all.

greg k-h

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

Re: When reviewers stop responding

[Greg KH]

On Tue, Jun 07, 2022 at 12:19:03PM -0500, Ian Pilcher wrote:
> On 11/19/21 01:08, Greg KH wrote:
> > As the merge window is now over, please just resend the patches.
> > Remember maintainers can not add anything to their trees usually for the
> > week before, and during the 2 weeks of, the merge window, so that might
> > account for the delay here.
> > 
> > Also, just resend because things do get lost.
> 
> Well ... 6 more months have passed without any response.  During that
> time I've resent the patch series 3 times.

lore.kernel.org links to those patches?

> > To help out, while waiting, why not review some patches for the same
> > subsystem on the mailing list to provide help for the maintainers?  That
> > help can go a long way in making sure your patches are reviewed.
> 
> Unfortunately, I just don't have the knowledge to do that.  I am not at
> all experienced with kernel development, nor do I have any knowledge of
> interrupt context code or Devicetree, which are the subject of the vast
> majority of patches to that subsystem.

If you have enough experience to send changes that you wish for others
to maintain over time, you should at least be able to review others
changes.  If not, how do you know your changes are correct to start
with?

> (I don't want to be more specific, because I'm not trying to "name &
> shame" anyone.  I'm sure that the people who work on this particular
> subsystem are simply overwhelmed.)
> 
> Is there anything else that I can do?  Should I just give up at this
> point?

Specifics matter here, links to the submission would be appreciated.
And again, please help review code, otherwise you are just asking others
to do work for you, which if you think about it, could be construed as a
bit selfish, and I don't think you mean it to be.

thanks,

greg k-h

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

Re: request for feedback before sending this patch

[Greg KH]

On Mon, Jun 06, 2022 at 10:51:00PM -0700, ozzloy wrote:
> i'd like to get some feedback before sending this off to the regular
> mailing list.
> i'm following Documentation/process/submitting-patches.rst and i think this
> is OK, but i thought that before and was wrong.
> 
> i'm not even sure if i should be asking here first, or sending this to the
> list.
> 
> are there any problems with the cleanup patch below?
> it fixes something that checkpatch.pl lists as an error for pointer
> location.
> 
> =
> >From 3ce7c7aaecaad6c28e0e1c17ce5b554274b0 Mon Sep 17 00:00:00 2001
> From: Daniel Watson 
> Date: Mon, 6 Jun 2022 11:31:31 -0700
> Subject: [PATCH] staging: r8188eu: fix declaration to match 'foo *bar'
> 
> put '*' next to variable to match kernel style from checkpatch
> 
> Signed-off-by: Daniel Watson 
> ---
>  drivers/staging/r8188eu/include/rtw_io.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/r8188eu/include/rtw_io.h
> b/drivers/staging/r8188eu/include/rtw_io.h
> index 6910e2b430e24..0e390eda5b4d3 100644
> --- a/drivers/staging/r8188eu/include/rtw_io.h
> +++ b/drivers/staging/r8188eu/include/rtw_io.h
> @@ -283,7 +283,7 @@ void free_io_queue(struct adapter *adapter);
>  void async_bus_io(struct io_queue *pio_q);
>  void bus_sync_io(struct io_queue *pio_q);
>  u32 _ioreq2rwmem(struct io_queue *pio_q);
> -void dev_power_down(struct adapter * Adapter, u8 bpwrup);
> +void dev_power_down(struct adapter *Adapter, u8 bpwrup);
> 
>  #define PlatformEFIOWrite1Byte(_a,_b,_c) \
>   rtw_write8(_a,_b,_c)
> -- 
> 2.34.1

Looks correct to me, send away!

> =
> 
> 
> 
> here's who i plan to send to:
> Larry Finger 
> Phillip Potter 
> Greg Kroah-Hartman 
> linux-stag...@lists.linux.dev

Yes.

> 
> should i include this list?
> linux-ker...@vger.kernel.org

If you really want to, sure.  It's not required.

> it is called a list of last resort here
> https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html
> but it is in the output of get-maintainer.pl for this patch.

It's in the output of all runs of that tool, as you say, it's the last
resort.

good luck!

greg k-h

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

Re: Supporting a USB HID device interface that is missing a interrupt input endpoint

[Greg KH]

On Thu, May 26, 2022 at 08:06:46PM +, Matt Silva wrote:
> Hey, Greg.
> 
> I went ahead and started implementing the changes in libusb as per your 
> recommendation. But I'm following up cause you asked about the usbhid-dump 
> output.
> 
> > But this really is not a HID device, right?
> 
> Well, Windows does decide to recognize it as a HID device. I captured some 
> packets send to the device's control endpoint of unknown transfer type with 
> URB function: URB Function: URB_FUNCTION_GET_MS_FEATURE_DESCRIPTOR (0x002a). 
> Perhaps that has something to do with this as my research says that MS OS 
> Descriptors indicate which driver Windows should use.

Ah, yeah, this info, and the hid descriptor dump you provided means this
is ment to be controlled from userspace with a vendor-specific program
like you are writing using libusb.

So you are on the right path, nice work!

greg k-h

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

Re: Supporting a USB HID device interface that is missing a interrupt input endpoint

[Greg KH]

On Wed, May 18, 2022 at 10:04:14PM +, Matt Silva wrote:
> Hi, Greg. Thanks for the response, I really appreciate it! Awesome to get a 
> reply from the man himself.
> 
> Probably wasn't the best from me to refer to the Windows software as a 
> driver. As far as I can tell it
> is just a userspace application using the Windows interface to communicate, 
> as you described below.
> 
> From my understanding, the device intends to operate as a HID device (unless 
> your comment below about
> all devices claiming to be HID when they're not on Windows applies here), it 
> even provides a HID descriptor
> with usages to Windows. It's also my understanding that for certain devices 
> with "quirks" that don't
> operate normally, the Linux kernel has quirks that allow these edge case 
> devices to operate as intended.

But this really is not a HID device, right?

What is the HID descriptor that it prints out?  Can you use the
'usbhid-dump' program that is part of the usbutils package to show the
report descriptors?

> So while your feedback about using libusb for OpenRGB in userspace definitely 
> doable, I was curious if this device
> would benifit from having support for its quirk added to the kernel so that 
> it can be exposed in userspace
> as it intends, rather than just solving my specific problem for OpenRGB. As 
> far as I can tell, the
> interface never communicated to directly through its single OUT endpoint. The 
> communication is through
> the control endpoint via a SET REPORT request. I did some reading and you are 
> correct, HID class
> interfaces require a interrupt in endpoint. But like I said, the fact that it 
> only communicates via the
> control endpoint made me think that maybe this requirement may not be 
> necessary for the interface
> to function as intended.

If this is all going through a "fake" SET REPORT command, in a
vendor-specific way, I would just recommend doing it all from userspace
using libusb like OpenRGB does for other devices.  No need to mess with
the kernel at all for a fake HID device like this.

good luck!

greg k-h

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

Re: How to track the source tree of kernel

[Greg KH]

On Wed, May 18, 2022 at 10:47:59PM +0800, chen.mingzheng wrote:
> Hi Guys,
> 
> Sorry to bother you all. I'm just starting learning linux with a rpi4b. I
> found the raspi source tree have many branches, which are different from the
> kernel source tree, which also have many branches. I want to know how should
> I track the source code. should I track all branches from the remote repo,
> or just stick to a specific branch? How did you do so that you can catch up
> to lastest kernel?

It all depends on what you want to do as to what tree/branch to work off
of and to track.

So, what exactly do you want to do?

thanks,

greg k-h

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

Re: Supporting a USB HID device interface that is missing a interrupt input endpoint

[Greg KH]

On Mon, May 16, 2022 at 11:40:09PM +, Matt Silva wrote:
> Hi, first time emailing here, so if there are any issues with my question, 
> let me know and I'll fix it.
> 
> Basically, I'm working with a USB HID microphone that also supports RGB 
> features. I'm working to reverse engineer the RGB features provided by a 
> proprietary Windows driver and add support to OpenRGB.

If this is a custom windows kernel driver, perhaps you don't need to
talk HID to the device at all?

Or is this just a device that is using the userspace Windows HID
interface to talk to the device directly without any kernel code needed
(that used to be the only way userspace programs could talk to USB
devices on Windows for vendor-specific devices, so they all claim to be
HID when they really are not.)

> The issue is that the interface that handles the RGB packets only has an OUT 
> interrupt endpoint (rather than an IN interrupt) and as such doesn't get 
> picked up by the usbhid driver (and therefore can't be picked up by the 
> HIDAPI library that OpenRGB uses). However, on Windows this interface is 
> detected as a HID device. I've narrowed down where this happens to 
> "drivers/hid/usbhid/hid-core.c:1350", and making some testing changes there 
> to check when the device idVendor, idProd, and interface number match and 
> then only check for endpoint being interrupt rather than input interrupt, I 
> can get the kernel to properly associate the interface with the usbhid driver.

A USB HID device has to have an interrupt IN endpoint to be HID
compliant from what I remember in the specification, so the kernel is
correct here.  But you should double check this with the specification
to be sure (they are free to download from usb.org).

> My main question is regarding how this change should be implemented.

Why not just talk directly to the device using libusb from userspace?
I don't know how openrgb works, but odds are there are other devices
that do not register as HID devices that it supports?

Hope this helps,

greg k-h

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

Re: UAPI syscall exception interpretation

[Greg KH]

On Thu, May 12, 2022 at 11:21:03PM +, Muhammad Ali wrote:
> From: Greg KH
> Sent: May 12, 2022 12:03 AM
> To: Muhammad Ali 
> Cc: Kernelnewbies@kernelnewbies.org 
> Subject: Re: UAPI syscall exception interpretation
> 
> >On Wed, May 11, 2022 at 09:19:42PM +, >Muhammad Ali wrote:
> >> Consider a file: ftpclient.c
> >> Only include is: #include 
> >> Then a few hundred lines of personal code.
> >> Then compiler/linker take in ftpcliebt.c and >produce a.out (statically or 
> >> dynamically linked, >consider both cases if it makes a licensing 
> >> >difference)
> >>
> >> Does the Linux-syscall-note say that a.out can >ALL be under any license 
> >> of your choice?
> >>
> >> Or do you have to note that your binary is under >License X and also 
> >> includes code which is under >license GPL-2.0-WITH-Linux-syscall-note?
> 
> >For legal issues, please contact a lawyer.  You >wouldn't ask a random
> >internet mailing list full of programmers questions >about dental care,
> >right?  :)
> >
> >Good luck!
> >
> >greg k-h
> 
> Happy to see you responded Greg,  since you have marked this issue as low 
> priority since 2020, see https://lkml.org/lkml/2020/2/23/105

Other things happened in 2020 that pushed this to the back of the list.

> If we could finally get some clarity or examples to illustrate the exception 
> and license, 2 years later, then that would be very nice, because I am not 
> the only one who is thinking that the current syscall exception text and 
> license.rst are not giving a clear interpretation as to when the GPL applies 
> and on what code it applies. What do I tell the lawyer? “Here’s some 
> conflicting licensing guide and license text and Greg said, on the mailing 
> list, that things will be ‘made obvious’ but nothing has changed so just 
> provide me with what you think”? Shouldn’t I be saying that sentence to the 
> kernel maintainers, instead?

If you have a lawyer that has issues with the current wording and you
need help with that, please let me know and I can put them in contact
with lawyers who can help them understand the issues involved.

thanks,

greg k-h

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

Re: UAPI syscall exception interpretation

[Greg KH]

On Wed, May 11, 2022 at 09:19:42PM +, Muhammad Ali wrote:
> Consider a file: ftpclient.c
> Only include is: #include 
> Then a few hundred lines of personal code.
> Then compiler/linker take in ftpcliebt.c and produce a.out (statically or 
> dynamically linked, consider both cases if it makes a licensing difference)
> 
> Does the Linux-syscall-note say that a.out can ALL be under any license of 
> your choice?
> 
> Or do you have to note that your binary is under License X and also includes 
> code which is under license GPL-2.0-WITH-Linux-syscall-note?

For legal issues, please contact a lawyer.  You wouldn't ask a random
internet mailing list full of programmers questions about dental care,
right?  :)

Good luck!

greg k-h

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

Re: Coding style operator precedence

[Greg KH]

On Fri, Apr 22, 2022 at 10:08:54PM +0800, Solomon Tan wrote:
> Hey all,
> 
> Could someone share what the coding style preference is where operator
> precedence is concerned?
> 
> I notice in the staging drivers that there are many instances where
> there are parenthesis in statements where operator precedence should be
> (in my opinion) obvious. Yet, there doesn't seem to be a patch to amend
> it. For example:
> 
> In vc04_services/interface/vchiq_arm/vchiq_core.c, line 2136, there is
> ```
> slot_zero->master.slot_last = first_data_slot + (num_slots / 2) - 1;
> ```
> It could just have been
> ```
> slot_zero->master.slot_last = first_data_slot + num_slots / 2 - 1;
> ```
> yet I do not see anyone patching it. Nothing is mentioned in the kernel
> docs about operator precedence. Checkpatch.pl doesn't highlight it
> as a coding style either. 

Because as-is, it is fine.

> What is the concensus regarding operator precedence in kernel coding
> style? The most relevant email thread I found suggests some feel the
> parenthesis shouldnt be there, while others would leave it there for
> readability.
> https://lore.kernel.org/linux-staging/yrypyev4ku3ei...@kroah.com/ 

Make it obvious when people read the code as we do not always remember
the precedence order.  We write code for people first, compilers second.

thanks,

greg k-h

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

Re: How to write to a PCIe config space during kernel boot up

[Greg KH]

On Wed, Apr 13, 2022 at 07:01:01AM +, Khalid F. Sabzwari wrote:
>  Thanks Ozgur for quick reply.The link you shared below seems to work with 
> MDIO interface.The PHY used on my board is Intel's i211 PHY which is 
> controlled by PCIe interface.I found this 
> link:https://docs.kernel.org/PCI/pci.html#how-to-access-pci-config-space
> 
> I never wrote a kernel code before, and am trying to just hack for an 
> experiment to write to config space of this PHY. so I will give it a try to 
> see if i can read/write to i211's config space, during early kernel boot 
> time, using pci_(read|write)_config_(byte|word|dword)

Do so in the driver that binds to the device, before it initializes it.
Not in the kernel core, otherwise in the kernel core you do not have
access to the needed pci structures.

thanks,

greg k-h

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

Re: Can't understand /proc/interrupts output for GICv3 case

['Greg KH']

On Tue, Apr 12, 2022 at 03:51:24PM +0900, Chan Kim wrote:
> Hi Greg KH and all,
> 
> I found how to find the irq number in my case! (char driver kernel module)
> I want to share it for reference to others.
> 
> add these two header files for this.
> #include 
> #include 
> 
> extern struct irq_desc *irq_to_desc(unsigned int irq);
> struct irq_desc *desc;
> 
> in the module _init function :
> 
> // find my irq number
> for(i=0;i desc = irq_to_desc(i);
> if (desc) {
> //printk("irq_desc(%d)->irq_data.hwirq = %ld\n", i,
> desc->irq_data.hwirq);
> if (desc->irq_data.hwirq == 47) break; // 47 is the hwirq
> number, (SPI 15)
> }
> }

No, please no.  Do NOT do this, it will break and not work well over
time, if it even works at all right now you are lucky.  Odds are, when
you reboot, it will not as irq numbers are never guaranteed to be the
same across boots.

Again, use the irq number given to you by your platform device bus.  It
should be much simpler than "iterate over all irqs and guess which one
we want to take" like you did here.

good luck!

greg k-h

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

Re: Can't understand /proc/interrupts output for GICv3 case

['Greg KH']

On Tue, Apr 12, 2022 at 11:18:03AM +0900, Chan Kim wrote:
> > You can replace all of the above code by just using the miscdevice
> > interface instead.  Please use that, it ensures that you do everything
> > properly and simplifies it all.

Again, use the misc device api please.

> > >   vaddr = ioremap(AXPU_BASE, 0x8);
> > 
> > Wait, where are you picking those random values from?
> 
> Yes, it now looks weird to me. I have passed the register address
> information in the device tree and the kernel already knows my device's
> address range. Then, how should I get this virtual io address in this
> driver? I need it to access some registers. How can I ask the system bus?

Use a platform driver and bind your driver to that device based on that
api.

> And my driver is a kernel module because I want to use it in ubuntu-20.04 on
> a virtual machine, I want it to be a kernel module that I can insmod or
> rmmod.(actually my job is to provide this virtual machine to some folks).
> And I cannot build the ubuntu image even if I change it to a platform device
> driver and add it in the kernel tree.

This all does not matter, just write a proper platform driver and all
will be fine.

> > >   ret = request_irq(6, axpu_irq_handler, IRQF_SHARED, "axpu_irq",
> > > _cdev);
> > 
> > Same for that, just picking 6 will not work, sorry.
> > 
> 
> Yes, that was my original question. How can I get my irq number (I know it's
> hwirq 47) and I peeked into kernel that irq 6 was assigned for the irq_desc.
> So I changed my driver to request irq 6 for my device and I found at least
> it works for now, all the register access and interrupts. I know this is not
> the solution and I'm curious how I should get the irq number of io virtual
> address in this situation.

Again, the platform driver interface will provide you with the needed
information.  We have thousands of working examples in the kernel tree.

> 
> > Perhaps take a look at the book, Linux Device Drivers, 3rd edition.
> > It's free online and should help you out a lot.
> > 
> > >   printk("request_irq returned %d\n", ret); // -EINVAL
> > >   printk(KERN_INFO "Device driver inserted ..done properly..\n");
> > >   return 0;
> > >
> > > r_device :
> > >   class_destroy(dev_class);
> > >
> > > r_class :
> > >   unregister_chrdev_region(dev,1);
> > >   return -1;
> > 
> > One final comment, don't make up error values like this, use real ERROR
> > codes.
> > 
> > thanks,
> > 
> > greg k-h
> 
> Yes, I've read the book sometimes (not the whole part) but if I read it now,
> I'll be able to more understand it. It's a bit outdated though. Why don't
> you update your book? :)

Because the publisher does not want to publish a new version.

thanks,

greg k-h

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

Re: Can't understand /proc/interrupts output for GICv3 case

[Greg KH]

On Mon, Apr 11, 2022 at 03:32:23PM +0100, Peter Maydell wrote:
> On Mon, 11 Apr 2022 at 15:22, Chan Kim  wrote:
> >
> >
> > > > > What bus type is your driver written for?
> > > > >
> > > > That sounds very logical. In my case I added it to system bus.
> > >
> > > What exactly do you mean by "system bus"?
> > >
> > I meant 'sysbus' in qemu code that I showed in the qemu code.
> > And I think it's the CPU bus.
> 
> The 'sysbus' is just QEMU's abstraction for "devices mapped into
> memory at a fixed physical address", ie simple MMIO devices that
> aren't on a complex bus like PCI or USB or SPI.

So, a platform_device in Linux kernel terms, right?

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

Re: Can't understand /proc/interrupts output for GICv3 case

['Greg KH']

On Mon, Apr 11, 2022 at 11:15:57PM +0900, Chan Kim wrote:
> 
> > > > What bus type is your driver written for?
> > > >
> > > That sounds very logical. In my case I added it to system bus.
> > 
> > What exactly do you mean by "system bus"?
> > 
> I meant 'sysbus' in qemu code that I showed in the qemu code.
> And I think it's the CPU bus.
> 
> > 
> > Where is your kernel code?
> > 
> This is the init function of my char driver. I thought if the struct cdev
> contains struct device, maybe I could use the struct device's of_node to
> call of_irq_get but it doesn't.
> And I remember I've seen the cdev in usually contained in the driver data of
> platform driver(?). Can I implement platform driver in kernel module form? 
> Below is the char driver init code. Currently it's request_irq(6, ... ) but
> I want to know out the number 6 using program. If you have any advice,
> please tell me.
> 
> static int __init chr_driver_init(void)
> {
>   int ret;
>   /* Allocating Major number */
>   if ((alloc_chrdev_region(, 0, 1, "axpu_Dev")) < 0) {
>   printk(KERN_INFO"Cannot allocate the major number..\n");
>   return -1;
>   }
> 
>   printk(KERN_INFO"Major = %d Minor = %d..\n",MAJOR(dev),MINOR(dev));
>   
>   /* creating cdev structure */
>   cdev_init(_cdev, );
>   axpu_cdev.owner = THIS_MODULE;
> 
>   /* Adding character device to the system */
>   if ((cdev_add(_cdev,dev,1)) < 0) {
>   printk(KERN_INFO "Cannot add the device to the
> system...\n");
>   goto r_class;
>   }
> 
>   /* creating struct class */
>   if ((dev_class = class_create(THIS_MODULE, "axpu_class")) == NULL) {
>   printk(KERN_INFO "cannot create the struct class...\n");
>   goto r_class;
>   }
> 
>   /* for interrupt test !! */
>   /*  for vanilla work-around.. already made by mkdev */
>   if ((device_create(dev_class, NULL, dev, NULL, "axpu_device")) ==
> NULL) {
>   printk(KERN_INFO "cannot create the device ..\n");
>   goto r_device;
>   }
>   else { printk(KERN_INFO "axpu_device created..\n"); }
>   /**/

You can replace all of the above code by just using the miscdevice
interface instead.  Please use that, it ensures that you do everything
properly and simplifies it all.

> 
>   vaddr = ioremap(AXPU_BASE, 0x8);

Wait, where are you picking those random values from?

That's not how drivers work in the kernel.  You have to have a bus pass
you a device.  Please register your driver with the proper bus type and
go from there.  The probe callback should be the place you set things up
based on the device and resources given to you by the bus.

You can't just randomly pick memory locations and think things will
work.

>   if(!vaddr)
>   {
>   printk(KERN_INFO"Failed to map the address.\n");
>   release_mem_region(AXPU_BASE,AXPU_SIZE);
>   return 1;
>   }
>   printk("- AXPU_BASE mapped at vaddr = %px\n", vaddr);
> 
>   ret = request_irq(6, axpu_irq_handler, IRQF_SHARED, "axpu_irq",
> _cdev);

Same for that, just picking 6 will not work, sorry.

Perhaps take a look at the book, Linux Device Drivers, 3rd edition.
It's free online and should help you out a lot.

>   printk("request_irq returned %d\n", ret); // -EINVAL
>   printk(KERN_INFO "Device driver inserted ..done properly..\n");
>   return 0;
> 
> r_device :
>   class_destroy(dev_class);
> 
> r_class :
>   unregister_chrdev_region(dev,1);
>   return -1;

One final comment, don't make up error values like this, use real ERROR
codes.

thanks,

greg k-h

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

Re: Can't understand /proc/interrupts output for GICv3 case

['Greg KH']

On Mon, Apr 11, 2022 at 10:13:42PM +0900, Chan Kim wrote:
> Hi, Greg K-H,
> Thanks for replyaing.
> > 
> > You ask the system for it.  It depends on the bus type your driver is
> > written for for how to do this.
> > 
> > For example, if you have a platform driver, you would call
> > platform_get_irq().  If you are a pci driver, the irq for your device is
> > already stored in the pci device structure passed into your probe
> function.
> > 
> > What bus type is your driver written for?
> > 
> That sounds very logical. In my case I added it to system bus.

What exactly do you mean by "system bus"?

> This is the qemu code making fdt. 
> 
> static void create_ab21q_axpu_device(const Ab21qMachineState *vms)
> {
> char *nodename;
> printf("create_ab21q_axpu_device called!\n");
> hwaddr base = vms->memmap[AB21Q_AXPU].base;
> hwaddr size = vms->memmap[AB21Q_AXPU].size;
> int irq = vms->irqmap[AB21Q_AXPU];
> const char compat[] = "ab21q-axpu";
> 
> sysbus_create_simple("ab21q-axpu", base, qdev_get_gpio_in(vms->gic,
> irq));
> 
> nodename = g_strdup_printf("/ab21q_axpu@%" PRIx64, base);
> qemu_fdt_add_subnode(vms->fdt, nodename);
> qemu_fdt_setprop(vms->fdt, nodename, "compatible", compat,
> sizeof(compat));
> qemu_fdt_setprop_sized_cells(vms->fdt, nodename, "reg", 2, base, 2,
> size);
> qemu_fdt_setprop_cells(vms->fdt, nodename, "interrupts",
>GIC_FDT_IRQ_TYPE_SPI, irq, 
>GIC_FDT_IRQ_FLAGS_LEVEL_HI);
> qemu_fdt_setprop_cell(vms->fdt, nodename, "interrupt-parent",
> vms->gic_phandle);
> 
> g_free(nodename);

This is qemu code, not kernel code.

> }
> 
> I understand it creates the device axpu and connects its irq output to a
> gpio input connected to gic interrupt controller. 

Again, this is qemu code, not kernel code.

> But this driver is not in the form of platform device/driver. (a char
> device). What function should I use to get the irq number in this case?
> I couldn't find a function with a likely name in the tags file for linux
> source.(5.4.188)

Where is your kernel code?

confused,

greg k-h

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

Re: Can't understand /proc/interrupts output for GICv3 case

[Greg KH]

On Mon, Apr 11, 2022 at 09:36:14PM +0900, Chan Kim wrote:
> Hi, 
> nobody's replying to my question.. so sad..
> I found the kernel makes an array (actually a radix tree) of 'irq_desc's. 
> And my hwirq (SPI 15) is assigned to one of these irq_descs while processing
> device tree.
> In my case it was assigned irq 6 (this irq is what is called virtual irq).
> So I registered the handler by request_irq(6,...) and the interrupt works
> fine.
> So now my question is : how can find my irq number (correct irq_desc number)
> in kernel driver module?

You ask the system for it.  It depends on the bus type your driver is
written for for how to do this.

For example, if you have a platform driver, you would call
platform_get_irq().  If you are a pci driver, the irq for your device is
already stored in the pci device structure passed into your probe
function.

What bus type is your driver written for?

hope this helps,

greg k-h

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

Re: kernel space: finding cpu usage of individual process/thread

[Greg KH]

On Wed, Mar 23, 2022 at 09:15:16PM +0530, Pintu Agarwal wrote:
> Hi,
> 
> For one of my requirements I need to find cpu usage or load_avg of an
> individual process or thread using "for_each_process_thread(process,
> thread)" where process/thread is a pointer to "task_struct".

Who is making such a crazy requirement?

Have you looked at how normal tools get this information today?  We have
loads of userspace examples and libraries that provide you this
information, no need to reinvent the wheel.

Unless this is a homework assignment.  Then that's up to you to solve,
not us :)

good luck!

greg k-h

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

Re: What to do with macros with do while (0) body

[Greg KH]

On Sat, Mar 19, 2022 at 08:25:34AM +0100, Philipp Hortmann wrote:
> Hi all,
> 
> please support me in what to do with the below macro as checkpatch seems to
> hate them.
> 
> In this case the macro is unused. Just remove macro?

Yes.

> When the macro is used how to remove this checkpatch message:
> CHECK: Macro argument reuse 'iobase' - possible side-effects?
> Even when iobase is just used in this macro this message does not go away.
> 
> I do prefer to make a function out of such macros but what is kernel
> standard?

Making it a function please.

> CHECK: Avoid CamelCase: 
> #864: FILE: drivers/staging/vt6655/mac.h:864:
> +#define MACvWriteCRC16_128(iobase, byRegOfs, wCRC)   \
> 
> CHECK: Avoid CamelCase: 
> #864: FILE: drivers/staging/vt6655/mac.h:864:
> +#define MACvWriteCRC16_128(iobase, byRegOfs, wCRC)   \
> 
> CHECK: Macro argument reuse 'iobase' - possible side-effects?
> #864: FILE: drivers/staging/vt6655/mac.h:864:
> +#define MACvWriteCRC16_128(iobase, byRegOfs, wCRC)   \
> +do { \
> + VNSvOutPortB(iobase + MAC_REG_PAGE1SEL, 1); \
> + VNSvOutPortW(iobase + byRegOfs, wCRC);  \
> + VNSvOutPortB(iobase + MAC_REG_PAGE1SEL, 0); \
> +} while (0)

checkpatch is right here, this is a horrid macro and can cause problems
if used incorrectly.  Make this a function.

thanks,

greg k-h

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

Re: ioctl number change / backwards compatibility doubt

[Greg KH]

On Sat, Mar 12, 2022 at 01:05:46PM +1300, Paulo Miguel Almeida wrote:
> On Mon, Jan 24, 2022 at 07:20:45AM +0100, Greg KH wrote:
> > On Mon, Jan 24, 2022 at 05:49:06PM +1300, Paulo Miguel Almeida wrote:
> > > On Sun, Jan 23, 2022 at 12:04:48PM +0100, Greg KH wrote:
> > > 
> > > when you told me to look for the userspace tool that interfaced with the
> > > ioctl, my interpretation was that you were referring to something akin
> > > to what /usr/bin/uname utility is to the syscall uname. Please correct me 
> > > if I'm wrong.
> > > 
> > > re: what calls the ioctl created by the driver.
> > > 
> > > I'm led to believe that users of this driver make ioctl sycall
> > > invocations directly from their application's source code like this:
> > > 
> > > #include "pi433_if.h" /* userspace driver header */
> > > #include /* ioctl */
> > > 
> > > int file_desc = open("/dev/pi433.0", O_RDWR);
> > > struct pi433_tx_cfg tx_cfg = {
> > >   .frequency = 43300,
> > >   .bit_rate = 4800,
> > >   ...
> > > };
> > > 
> > > int ret_val = ioctl(file_desc, PI433_IOC_WR_TX_CFG, tx_cfg);
> > > 
> > 
> > Yes, sorry for the confusion, this is what I am referring to.  Where is
> > that userspace code as that is the code you will be needing to change if
> > you want to change this ioctl interface.
> > 
> > thanks,
> > 
> > greg k-h
> 
> Hi Greg, 
> 
> The original author replied my email with that question.  He sent me
> some the code used to interface with char device, however, the source
> code he provided me is already incompatible with the current version of
> the driver:
> 
> #include "rfxx.h" (file header name has changed)
> 
> int main(int argc, char *argv[])
> {
>   ...
>   struct rfxx_send_config sendConfig; (struct name has changed)
>   ...
> fd = open("/dev/rf69_0.0", O_RDWR); *(char device name changed)*
>   ...
>   sendConfig.data_mode = packet; *(property doesn't exist)*
> ...
>   (IOCTL call has a different name)
>   ret = ioctl(fd, RFXX_IOC_WR_SEND_CONFIG, );
> if (ret == -1)
>   ...
> }
> 
> Assuming that I tweak these tools he provided me with and publish them,
> will I then be able to tweak the structures passed back and forth via
> ioctl? (do I need to change ioctl number in this case?) 
> 
> The reason why I'm asking this is because given the fact that other
> developers could have written similar code for interfacing with the
> driver (and that we will never know because code is proprietary), I
> won't be sure that I've changed all occurences at the same time, right?
> 
> All in all, please correct if there are gaps in this train of thought.
> 
> - If a change doesn't break *compiled* code (such as struct renaming) 
> then it's 'okay' to make the change ? (this has happened in the this
> driver before)

For staging drivers, the user/kernel api usually needs to be changed, so
yes, as long as you can change the tools that are being used to talk to
this api, you should be fine.

thanks,

greg k-h

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

Re: "Disappearing" file in Documentation/ABI/testing

[Greg KH]

On Mon, Mar 14, 2022 at 12:36:51PM -0500, Ian Pilcher wrote:
> I am working on resubmitting a patch that adds an entry to
> Documentation/ABI/testing/sysfs-block.  That file does not exist in
> Linus's most recent tree.  All (presumably) of the entries documented in
> that file have been merged into Documentation/ABI/stable/sysfs-block.
> 
> How should I handle this?  Should my patch now add its entry to the
> "stable" file, or should it recreate the "testing" file?

It should be in "stable" as it is going to be a stable api :)

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

Re: USB CDC performance test

[Greg KH]

On Mon, Mar 07, 2022 at 01:08:28PM +0530, Mithran B wrote:
> On Fri, 4 Mar 2022 at 20:31, Greg KH  wrote:
> 
> > On Fri, Mar 04, 2022 at 08:06:55PM +0530, Mithran B wrote:
> > > On Fri, 4 Mar 2022 at 19:48, Greg KH  wrote:
> > >
> > > > On Fri, Mar 04, 2022 at 04:27:50PM +0530, Mithran B wrote:
> > > > > Hello,
> > > > >
> > > > > In Host and Gadget systems, enabled the USB CDC drivers.
> > > > > Then nodes are created as /dev/ttyAcm0 and /dev/ttyGs0.
> > > > > Then opened the nodes and write and read back the data.
> > > > > It is working.
> > > > >
> > > > > I want to test the performance of this interface and drivers.
> > > > > Do we have any utility for this?
> > > > > How to do the performance test?
> > > >
> > > > What exactly do you want to measure?  Determine that first before
> > trying
> > > > to find a test for that.  Without knowing what you want to measure,
> > it's
> > > > hard to tell you how to measure it :)
> > > >
> > > > good luck!
> > > >
> > > > greg k-h
> > > >
> > >
> > > Thank you.
> > > I want to send the data at the rate of 5mbps from Host device to target
> > > device using USB CDC - ACM.
> > > In termios functions, how to configure this 5mbps as baud rate and USB
> > > payload size, i.e. packet
> > > size to be in 2K bytes.
> >
> > There is no "baud rate" for usb cdc devices, really, as you have tried
> > this already, right?
> >
> > Just send the data as fast as you can, with the largest chunks of data
> > that you have (do not send it byte by byte to the kernel), and you
> > should be fine.
> >
> > Are you sure that your device can handle that type of data rate?  That's
> > almost always the limiting factor.
> >
> > good luck!
> >
> > greg k-h
> >
> 
> In USB CDC, any software flow control mechanism is implemented?

The specification is public on the usb.org web site, if you are curious.
There is no need for "flow control" like you are used to for older
serial connections with USB, the way USB works handles it automatically
(the host drives the connection, if the device is full, it tells the
host to wait automatically).

> Any hardware flow control mechanism there?

Other than the normal USB flow control mechanism?  No, why would there
be?

> How to enable this software flow control mechanism in kernel device drivers?

what software flow control?

> Any other information related to this is good for us.

For whom?  What exactly have you tried and what were the results?

thanks,

greg k-h

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

Re: USB CDC performance test

[Greg KH]

On Fri, Mar 04, 2022 at 08:06:55PM +0530, Mithran B wrote:
> On Fri, 4 Mar 2022 at 19:48, Greg KH  wrote:
> 
> > On Fri, Mar 04, 2022 at 04:27:50PM +0530, Mithran B wrote:
> > > Hello,
> > >
> > > In Host and Gadget systems, enabled the USB CDC drivers.
> > > Then nodes are created as /dev/ttyAcm0 and /dev/ttyGs0.
> > > Then opened the nodes and write and read back the data.
> > > It is working.
> > >
> > > I want to test the performance of this interface and drivers.
> > > Do we have any utility for this?
> > > How to do the performance test?
> >
> > What exactly do you want to measure?  Determine that first before trying
> > to find a test for that.  Without knowing what you want to measure, it's
> > hard to tell you how to measure it :)
> >
> > good luck!
> >
> > greg k-h
> >
> 
> Thank you.
> I want to send the data at the rate of 5mbps from Host device to target
> device using USB CDC - ACM.
> In termios functions, how to configure this 5mbps as baud rate and USB
> payload size, i.e. packet
> size to be in 2K bytes.

There is no "baud rate" for usb cdc devices, really, as you have tried
this already, right?

Just send the data as fast as you can, with the largest chunks of data
that you have (do not send it byte by byte to the kernel), and you
should be fine.

Are you sure that your device can handle that type of data rate?  That's
almost always the limiting factor.

good luck!

greg k-h

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

Re: USB CDC performance test

[Greg KH]

On Fri, Mar 04, 2022 at 04:27:50PM +0530, Mithran B wrote:
> Hello,
> 
> In Host and Gadget systems, enabled the USB CDC drivers.
> Then nodes are created as /dev/ttyAcm0 and /dev/ttyGs0.
> Then opened the nodes and write and read back the data.
> It is working.
> 
> I want to test the performance of this interface and drivers.
> Do we have any utility for this?
> How to do the performance test?

What exactly do you want to measure?  Determine that first before trying
to find a test for that.  Without knowing what you want to measure, it's
hard to tell you how to measure it :)

good luck!

greg k-h

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

Re: How to compile source code of new kernel specifically for my pc hardware with uefi secure boot.

[Greg KH]

On Tue, Mar 01, 2022 at 04:42:53PM +0530, Guddla Rupesh wrote:
> Someone of you asked what is the need of compiling source code of kernel
> and I am doing so due to the following reasons.
> 
> The main issues are when I click the shutdown button in desktop
> environments like gnome, mate the system is not shutting down immediately.
> When I run the command halt in terminal the monitor gets turned off but
> still the cpu runs a long time until I switch off the power.

How do you know this is a kernel issue?  Sounds like userspace still has
something to do to shut down.  Look into that first.

You can verify this by rebooting from the kernel directly using the
specific sysrq key combination.  I'll let you read the documentation to
find what that is as it can cause data loss if used without syncing the
disks first, so be careful.

> Previously I have tried to connect to internet through android tethering
> and the connection turns off with in 6 minutes and so I have tried a number
> of ways such as installing android udev rools and trying the commands

That sounds like an android device issue, not the kernel problem.  Not
much the kernel can do when the device shuts off.

> Now the issue is when I want to copy files from android smartphone to pc
> and connect the phone to pc the system is showing error as usb device not
> recognised.

Which USB device exactly?

> Most of the time I work using ffmpeg tool and so I have installed open CL
> packages like beignet, beignet devel, opencl headers, ocl-dev, clinfo
> packages. When I issue the command clinfo I am getting errors as no open CL
> devices found etc.,.

Do you have the needed hardware for the cl libraries?

Try solving one at a time.

good luck!

greg k-h

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

Re: How to compile source code of new kernel specifically for my pc hardware with uefi secure boot.

[Greg KH]

On Mon, Feb 28, 2022 at 11:14:32PM +0530, Guddla Rupesh wrote:
> Hi I am Rupesh from India and I have pc i3 processor and h510 motherboard
> It has uefi. I have installed open suse tumblewood and all the packages
> have been updated. As the default kernel provided by open suse tumblewood
> is not working properly I want to compile source code of new kernel which
> is obtained from kernel.org and the kernel source code present in
> /usr/src/linux*** but I can't.

Independant of you running a custom kernel on your machine (hint, turn
off secure boot in your BIOS/UEFI in order to load an unsigned kernel
image, or add your own keys to the BIOS that you create yourself), what
is wrong with the tumbleweed kernel that is not working for you?  That
kernel should be very close to the upstream kernel.

thanks,

greg k-h

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

Re: make menuconfig and make j$(nproc) throwing errors

[Greg KH]

On Thu, Feb 24, 2022 at 05:40:33AM -0500, Aruna Hewapathirane wrote:
> On Thu, Feb 24, 2022 at 1:46 AM Greg KH  wrote:
> >
> > On Wed, Feb 23, 2022 at 10:58:45PM -0500, Aruna Hewapathirane wrote:
> > > And I tried to build without make menuconfig and make is telling me I
> > > need 'bison' ? Why do I need bison ? Since when
> > > did we need bison ? See below for details.
> > >
> > > aruna@debian:/media/aruna/linux-next/home/linux-5.16.10$ make -j$(nproc)
> > >   DESCEND objtool
> > >   HOSTCC  scripts/asn1_compiler
> > >   YACCscripts/genksyms/parse.tab.[ch]
> > > /bin/sh: 1: bison: not found
> >
> > You need bison to build the kernel, sorry, please install it.
> Oh my, you actually went through that mess ? I will do so thank you.
> >
> > > make[2]: *** [scripts/genksyms/Makefile:21:
> > > scripts/genksyms/parse.tab.c] Error 127
> > > make[1]: *** [scripts/Makefile.build:549: scripts/genksyms] Error 2
> > > make[1]: *** Waiting for unfinished jobs
> > > :1:10: fatal error: libelf.h: No such file or directory
> >
> > You also need libelf.
> I will install libelf-dev as well thanks.
> 
> Greg, now make complains it requires 'flex' ?

Yes, please install that.

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

Re: make menuconfig and make j$(nproc) throwing errors

[Greg KH]

On Wed, Feb 23, 2022 at 10:58:45PM -0500, Aruna Hewapathirane wrote:
> And I tried to build without make menuconfig and make is telling me I
> need 'bison' ? Why do I need bison ? Since when
> did we need bison ? See below for details.
> 
> aruna@debian:/media/aruna/linux-next/home/linux-5.16.10$ make -j$(nproc)
>   DESCEND objtool
>   HOSTCC  scripts/asn1_compiler
>   YACCscripts/genksyms/parse.tab.[ch]
> /bin/sh: 1: bison: not found

You need bison to build the kernel, sorry, please install it.

> make[2]: *** [scripts/genksyms/Makefile:21:
> scripts/genksyms/parse.tab.c] Error 127
> make[1]: *** [scripts/Makefile.build:549: scripts/genksyms] Error 2
> make[1]: *** Waiting for unfinished jobs
> :1:10: fatal error: libelf.h: No such file or directory

You also need libelf.

thanks,

greg k-h

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

Re: Why doesn't the GCC give any warning to these unused variables in the Linux kernel?

[Greg KH]

On Sun, Feb 20, 2022 at 07:39:13AM +, Song Zhi wrote:
> Normally, the compiler warns if a variable is declared but is never 
> referenced. In the Linux kernel source code, some unused functions and 
> variables are marked __atrribute__((unused)).
> 
> 
> ==> https://livegrep.com/search/linux?q=__attribute__((unused))
> 
> 
> GCC, on the other hand, does not provide any warnings for these unused and 
> unmarked variables like the integer flags in 
> kernel/sched/idle.c#427
>  .
> 
> 
> Why?

Because we do not enable that build warning as it is mostly useless for
kernel code due to how different apis work inside the kernel.

Try enabling it yourself and see all of the noise that happens.

greg k-h

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

Re: ioctl number change / backwards compatibility doubt

[Greg KH]

On Mon, Jan 24, 2022 at 05:49:06PM +1300, Paulo Miguel Almeida wrote:
> On Sun, Jan 23, 2022 at 12:04:48PM +0100, Greg KH wrote:
> > On Sun, Jan 23, 2022 at 08:55:30PM +1300, Paulo Miguel Almeida wrote:
> > > 
> > > I googled a fair bit of time and I'm 99% confident that there isn't such
> > > userspace/lib tool so I guess this will have done the hard way :(
> > 
> > If there is no tool, why was the ioctl code written at all?  Something
> > had to call it.
> > 
> 
> when you told me to look for the userspace tool that interfaced with the
> ioctl, my interpretation was that you were referring to something akin
> to what /usr/bin/uname utility is to the syscall uname. Please correct me 
> if I'm wrong.
> 
> re: what calls the ioctl created by the driver.
> 
> I'm led to believe that users of this driver make ioctl sycall
> invocations directly from their application's source code like this:
> 
> #include "pi433_if.h" /* userspace driver header */
> #include /* ioctl */
> 
> int file_desc = open("/dev/pi433.0", O_RDWR);
> struct pi433_tx_cfg tx_cfg = {
>   .frequency = 43300,
>   .bit_rate = 4800,
>   ...
> };
> 
> int ret_val = ioctl(file_desc, PI433_IOC_WR_TX_CFG, tx_cfg);
> 

Yes, sorry for the confusion, this is what I am referring to.  Where is
that userspace code as that is the code you will be needing to change if
you want to change this ioctl interface.

thanks,

greg k-h

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

Re: how to fix section mismatch warning after inserting #pragma GCC optimize ?

[Greg KH]

On Sun, Jan 23, 2022 at 07:48:01PM +0900, Chan Kim wrote:
> Hello all,
> 
>  
> 
> In linux 5.4.21 source code, I put
> 
> #pragma GCC push_options
> 
> #pragma GCC optimize ("O0")

Do not do that.  Bad things will happen, the kernel really does not like
this at all.

Why do you want to build the kernel with "O0"?  What problem are you
trying to solve that you think this will resolve it?

Also, 5.4.21 is very old and obsolete and known insecure.  Please use a
more modern kernel version.

thanks,

greg k-h

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

Re: ioctl number change / backwards compatibility doubt

[Greg KH]

On Sun, Jan 23, 2022 at 08:55:30PM +1300, Paulo Miguel Almeida wrote:
> > > 1: Given the driver's history and ioctl number conflit, is the backwards
> > > compatibility something to be kept or not to be taken into consideration
> > > as ioctl numbering rules weren't followed?
> > 
> > Try to find out who is using these ioctls.  If you can change the
> > userspace tool at the same time, all is fine.  If not, then there can be
> > problems.
> 
> Apologies for the delay, I had emailed the original author and I was waiting 
> for his reply before I could answer this. It turns out I haven't gotten
> an official answer from him yet. (I do understand that he might be busy)
> 
> I googled a fair bit of time and I'm 99% confident that there isn't such
> userspace/lib tool so I guess this will have done the hard way :(

If there is no tool, why was the ioctl code written at all?  Something
had to call it.


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

Re: How to Convert Legacy Kernel Modules for modern Kernels

[Greg KH]

On Fri, Jan 21, 2022 at 04:21:18PM +0800, Tianrui Wei wrote:
> >> If there're not out of box solutions, is there a way I could view the
> >> API changes in every subsystem clearly? For example, this particular
> >> commit[^1] shows the second return argument is being removed from
> >> ki_complete, and it took a lot of fishing down the lkml to do. Perhaps
> >> there is a simpler way?
> >
> > Use git itself to track the changes in apis.  You can see all changes to
> > a .h file by doing:
> > git log -p path/to/file
> > and then see where the api got changed.
> 
> This is a really good suggestion, and it's also the way I approach
> recent kernel modules. However some specifically ancient kernel
> modules is rather difficult to use this approach.

We have git history going back to Linux 0.1 so this should work.  If
not, then do the normal 'does it build' test.  APIs are almost always
changed in ways that break the build.

> > It usually isn't that difficult to forward port a driver, but it all
> > depends on the age of the code, and what it actually does.  Do you have
> > a link to the code you wish to drag forward?
> 
> The specific driver I had in mind is a PCIE driver for a Xilinx IP
> block. It's under
> https://www.xilinx.com/products/boards-and-kits/ek-k7-kc705-g.html#resources
> in a zip folder called rdf0281-kc705-base-trd-2014-3.zip. Everyone
> with a xilinx account could download the folder. Unfortunately its
> header claims it contains confidential information from Xilinx, as
> such I'm a bit wary to post it online.

Please get support from xilix for stuff like this.  You are paying for
it from them, so please take advantage of it.  Especially if they claim
that their code is not GPLv2 compatible, you want them to take that
legal risk, not you :)

greg k-h

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

Re: How to Convert Legacy Kernel Modules for modern Kernels

[Greg KH]

On Thu, Jan 20, 2022 at 06:10:31PM +0800, Tianrui Wei wrote:
> Hi,
> 
> I was wondering if there're any tools/scripts in Linux that'd help me
> to convert legacy kernel modules for using on a modern Linux (Kernel >
> 5.0) system?

It depends on the driver you wish to convert.  For wireless drivers,
there was the "linux backport project" that provided scripts and tools
to do this type of work.  For other subsystems, I do not think anyone
ever did so as it's both not that hard, and also very specific to the
code that you are trying to convert.

> If there're not out of box solutions, is there a way I could view the
> API changes in every subsystem clearly? For example, this particular
> commit[^1] shows the second return argument is being removed from
> ki_complete, and it took a lot of fishing down the lkml to do. Perhaps
> there is a simpler way?

Use git itself to track the changes in apis.  You can see all changes to
a .h file by doing:
git log -p path/to/file
and then see where the api got changed.

It usually isn't that difficult to forward port a driver, but it all
depends on the age of the code, and what it actually does.  Do you have
a link to the code you wish to drag forward?  You can also always add it
to the in-kernel drivers/staging/ area and have others help out with
this effort.

good luck!

greg k-h

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

Re: ioctl number change / backwards compatibility doubt

[Greg KH]

On Mon, Jan 17, 2022 at 08:01:25PM +1300, Paulo Miguel Almeida wrote:
> Hi everyone,
> 
> Context:
> 
> I've been working on a driver called pi433 in the staging area and it 
> basically exposes a char device so the user can read/write stuff to
> it while obtaining tx/rx configuration via ioctl calls.
> 
> Tx/Rx configurations are both structs that (ideally) would be exposed
> to the userspace to let the developer to #include it on their code.
> 
> Info that *might* be relevant about this driver:
> 
> - This driver went straight to the staging area due to a few TODOs
>   listed by the original author. 
> - The ioctl Code and Seq numbers are conflicting with the ones listed
>   in the ioctl-numbers.rst

Not many people ever look at that file, and it is ok to have conflicts
as the same tool should never have to handle multiple drivers where a
conflict happens.

> Problem:
> 
> I realized that one of the structs used to pass/retrieve info needs
> to have some of its members changed (data type and etc)

Great!

> Questions:
> 
> 1: Given the driver's history and ioctl number conflit, is the backwards
> compatibility something to be kept or not to be taken into consideration
> as ioctl numbering rules weren't followed?

Try to find out who is using these ioctls.  If you can change the
userspace tool at the same time, all is fine.  If not, then there can be
problems.

> 2: The original author lists on the TODO file of the driver that 'he is
> afraid that using ioctl wasn't a good idea'. I pondered the alternatives
> and, *in case I can get rid of ioctl*, sysfs || configfs could be used. Does
> anyone suggests a different approach?

Same answer as above, it depends on what userspace tool is using these
ioctls.  Also it depends on what they do.  Many informational ioctls can
just be replaced with sysfs files, and many configuration ioctls can be
replaced with configfs, but for other things, sometimes you need an
ioctl.

So it depends.  Try to get ahold of the userspace side and then you can
usually work it out.

thanks,

greg k-h

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

Re: Where to find the information how to write a state of the art USB driver?

[Greg KH]

On Thu, Jan 13, 2022 at 08:01:04PM +0100, Greg KH wrote:
> On Thu, Jan 13, 2022 at 07:54:19PM +0100, Philipp Hortmann wrote:
> > On 1/13/22 4:33 PM, Greg KH wrote:
> > > On Thu, Jan 13, 2022 at 07:39:38AM +0100, Philipp Hortmann wrote:
> > > > On 1/12/22 10:54 AM, Greg KH wrote:
> > > > > That driver tried to be an example for an unknown device, doing 
> > > > > multiple
> > > > > different things that no single driver/device would probably ever 
> > > > > need.
> > > > > Also it can almost always just be replaced with a simple userspace
> > > > > program using libusb, as I bet your driver could be replaced with as
> > > > > well, right?
> > > > Yes it can be replaced by a userspace program but even this is not 
> > > > required.
> > > It is an issue if you are trying to write a new driver.  We do not take
> > > new drivers into the kernel tree if they can be in the kernel instead.
> > > 
> > 
> > Sorry I did not clearly express what I plan to do. I plan to do maintenance
> > and bug fixes on the kernel.
> 
> That's wonderful, try starting out in drivers/staging/*/TODO for lots of
> things that need work.

And, there are USB drivers in there as well, if that is what you are
interested in working on.

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

Re: Where to find the information how to write a state of the art USB driver?

[Greg KH]

On Thu, Jan 13, 2022 at 07:54:19PM +0100, Philipp Hortmann wrote:
> On 1/13/22 4:33 PM, Greg KH wrote:
> > On Thu, Jan 13, 2022 at 07:39:38AM +0100, Philipp Hortmann wrote:
> > > On 1/12/22 10:54 AM, Greg KH wrote:
> > > > That driver tried to be an example for an unknown device, doing multiple
> > > > different things that no single driver/device would probably ever need.
> > > > Also it can almost always just be replaced with a simple userspace
> > > > program using libusb, as I bet your driver could be replaced with as
> > > > well, right?
> > > Yes it can be replaced by a userspace program but even this is not 
> > > required.
> > It is an issue if you are trying to write a new driver.  We do not take
> > new drivers into the kernel tree if they can be in the kernel instead.
> > 
> 
> Sorry I did not clearly express what I plan to do. I plan to do maintenance
> and bug fixes on the kernel.

That's wonderful, try starting out in drivers/staging/*/TODO for lots of
things that need work.

Messing around with old USB drivers that "just work" and you don't have
the hardware for, might be a tough thing to work on as a beginning task.
No need to touch things that no one is complaining about if you can help
it :)

thanks,

greg k-h

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

Re: Where to find the information how to write a state of the art USB driver?

[Greg KH]

On Thu, Jan 13, 2022 at 04:33:50PM +0100, Greg KH wrote:
> On Thu, Jan 13, 2022 at 07:39:38AM +0100, Philipp Hortmann wrote:
> > On 1/12/22 10:54 AM, Greg KH wrote:
> > > That driver tried to be an example for an unknown device, doing multiple
> > > different things that no single driver/device would probably ever need.
> > > Also it can almost always just be replaced with a simple userspace
> > > program using libusb, as I bet your driver could be replaced with as
> > > well, right?
> > Yes it can be replaced by a userspace program but even this is not required.
> 
> It is an issue if you are trying to write a new driver.  We do not take
> new drivers into the kernel tree if they can be in the kernel instead.

That should be:
if they can be written in userspace instead.


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

Re: Where to find the information how to write a state of the art USB driver?

[Greg KH]

On Thu, Jan 13, 2022 at 07:39:38AM +0100, Philipp Hortmann wrote:
> On 1/12/22 10:54 AM, Greg KH wrote:
> > That driver tried to be an example for an unknown device, doing multiple
> > different things that no single driver/device would probably ever need.
> > Also it can almost always just be replaced with a simple userspace
> > program using libusb, as I bet your driver could be replaced with as
> > well, right?
> Yes it can be replaced by a userspace program but even this is not required.

It is an issue if you are trying to write a new driver.  We do not take
new drivers into the kernel tree if they can be in the kernel instead.

> For the USB LCD a userspace program is available from vendor.

Great!

> For the USB to serial Adapter the driver exists in the kernel ch341.c.
> It appears as a ttyUSB0 device.

For devices that need to show up to userspace as a common device type
(like a serial port), we need to have a kernel driver, so this is to be
expected.

> I think what happens to very custom drivers that could be userspace programs
> can be seen in the file /drivers/usb/misc/usblcd.c
> - It is written in 2005 and is only supporting one device from one vendor.
> - I cannot find/buy a suitable device.
> - I have tried two times to contact the author of the driver but:
> The response from the remote server was:
> 550 5.1.1 : Recipient address rejected: User unknown
> - The idVendor = 0x10D2 does also not help because RayComposer - R. Adams
> does not response and does not seam to offer such products.

What is the problem with this driver?  If it is not hurting anyone, and
still builds, it's not causing any problems.

> To me it is unused code but how to verify? When it is unused what does the
> kernel do with it? Putting it to the staging area?

Why do you want to delete it?

We can remove old drivers that no one uses, we do that all the time.
But usually that is because the maintance burden on them get too high
and we determine that no one actually uses the thing.  This driver
doesn't seem to be causing any problems that I can see, so why delete
it?

That being said, if you do think it should be removed, great, let's do
so and if someone later shows up that uses it, we can trivially add it
back.  Just submit a patch to do so.

But this doesn't have much to do with your original question, so I'm
confused as to what usblcd.c has to do with writing a new USB driver?

thanks,

greg k-h

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

Re: Where to find the information how to write a state of the art USB driver?

[Greg KH]

On Tue, Jan 11, 2022 at 09:09:31PM +0100, Philipp Hortmann wrote:
> On 1/11/22 9:51 AM, Greg KH wrote:
> > On Mon, Jan 10, 2022 at 10:31:28PM +0100, Philipp Hortmann wrote:
> > > Hi all,
> > > 
> > > template usb-skeleton.c is working but outdated, documentation is helpful
> > > but years old and checkpatch.pl is giving hints to deprecated functions.
> > > This information is helpful but it does not show the way how to write a
> > > state of the art USB driver. Where to find this information? In the USB
> > > mailing list? By checking in git on which files most maintenance 
> > > activities
> > > were done?
> > 
> > First off, what do you mean by "state of the art"?  USB drivers are
> 
> Program code that is using the latest functions, macros and is up to date.
> Simply code that you like or consider best.

It all depends on the use-case for what is the "best".  If you have a
slow device, and only need control/bulk USB transfers, that is one type
of design pattern of a USB driver, while higher throughput requirements
using streams is another, and data that can be lossy using isoc
endpoints is yet another.

So it will depend.

> > almost never just a USB driver.  The USB portion of the driver is the
> > "simple" part.  The "real" part of the driver is going to be doing
> > whatever functionality the device is (i.e. sound device, keyboard
> > device, video device, etc.)
> > 
> > USB is just a dumb pipe.  The USB portion of your driver just needs to
> > set up the pipes, and get the data flowing in them.  How you deal with
> > that data is going to be the real work you have to do, and the majority
> > of the driver size.  Otherwise you really do not even need a USB driver,
> > and you can just do everything from userspace and use libusb to
> > read/write to the USB device directly.
> > 
> > If you have a new driver you need to write, look at the existing drivers
> > for guidance, and the documentation.  Then submit it to the linux-usb
> > mailing list for review, the people there will help you out with any
> > portions that you have problems with.
> 
> Intention of this email was to not bother the community to much as I am a
> newbie.
> 
> > 
> > So, what have you tried so far that is not working and what type of
> > device are you trying to control that needs a new USB driver for?
> 
> No new driver and no new device. I want to do maintenance on old drivers.

Doing maintenance on old drivers that currently work well is hard
without having the hardware for them and finding a real problem with the
driver itself.  So start with drivers for devices that you have today,
and look and see if you can find any throughput issues or anything else.

But again, that's going to be very device/type specific as to what needs
to happen there.

> I
> have not chosen one yet as I want to practice first to get more into
> details. I have adapted the usb-skeleton.c for a USB to serial adapter and
> for a USB LCD Display. When I am doing it right the usb-skeleton.c is
> working very well. The reason why I am asking is because very experienced
> kernel developers have said it is "out of date" and want to delete it
> because it is so bad and so wrong. I do not understand what is so bad and so
> wrong.

That driver tried to be an example for an unknown device, doing multiple
different things that no single driver/device would probably ever need.
Also it can almost always just be replaced with a simple userspace
program using libusb, as I bet your driver could be replaced with as
well, right?

When I wrote that original usb skeleton driver, there was still many
different types of USB devices out there that we did not support, and so
an example driver was one way to help others out.  Given that Linux now
supports all USB devices and types, it's not so useful as if you need to
support a new one, it usually just requires you to modify an existing
driver.  New USB device types are, thankfully, quite rare these days,
with most of the crazy new things being able to be controlled directly
from userspace.

thanks,

greg k-h

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

Re: Where to find the information how to write a state of the art USB driver?

[Greg KH]

On Mon, Jan 10, 2022 at 10:31:28PM +0100, Philipp Hortmann wrote:
> Hi all,
> 
> template usb-skeleton.c is working but outdated, documentation is helpful
> but years old and checkpatch.pl is giving hints to deprecated functions.
> This information is helpful but it does not show the way how to write a
> state of the art USB driver. Where to find this information? In the USB
> mailing list? By checking in git on which files most maintenance activities
> were done?

First off, what do you mean by "state of the art"?  USB drivers are
almost never just a USB driver.  The USB portion of the driver is the
"simple" part.  The "real" part of the driver is going to be doing
whatever functionality the device is (i.e. sound device, keyboard
device, video device, etc.)

USB is just a dumb pipe.  The USB portion of your driver just needs to
set up the pipes, and get the data flowing in them.  How you deal with
that data is going to be the real work you have to do, and the majority
of the driver size.  Otherwise you really do not even need a USB driver,
and you can just do everything from userspace and use libusb to
read/write to the USB device directly.

If you have a new driver you need to write, look at the existing drivers
for guidance, and the documentation.  Then submit it to the linux-usb
mailing list for review, the people there will help you out with any
portions that you have problems with.

So, what have you tried so far that is not working and what type of
device are you trying to control that needs a new USB driver for?

thanks,

greg k-h

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

Re: X86 : system call

[Greg KH]

On Sun, Dec 12, 2021 at 12:34:54PM +0530, Muni Sekhar wrote:
> Also, could someone please point me to a document which explains about
> "how to add a new system call" and the "system call flow from user
> space to kernel space" in X86 ARCHITECTURE (32-BIT AND 64-BIT).

There are many documents online that show both of these already.  Have
you used a search engine first?

Both of these are usually questions that students are asked for
assignments, good luck in class!

greg k-h

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

Re: PCI: latency

[Greg KH]

On Fri, Dec 03, 2021 at 10:30:58PM +0530, Subhashini Rao Beerisetty wrote:
>  [ Please keep me in CC as I'm not subscribed to the list]
> 
> Hi all,
> 
> We are using the Linux OS on an x86_64 machine. I need to measure the
> PCIe latency on my system, does kernel have any latency measurement
> module for the PCIe bus?

How exactly are you going to define PCIe latency?

And what is this going to be used for?

thanks,

greg k-h

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

Re: pseudonymous or anonymous testing

[Greg KH]

On Fri, Dec 03, 2021 at 08:06:46PM +0100, Tarif H wrote:
> Hi all,
> 
> I know the official guidelines explicitly state that when submitting patches
> to the kernel the contributions must be signed with a real name and e-mail
> address, the reasons for this seem to be clear to me.
> The guidelines are less explicit when it comes to the tested-by field. Is it
> out of question to test a contribution and report the result using a
> pseudonym, even if it comes with a valid e-mail address?

No, please use real names for tested-by whenever possible as well.

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

Re: When reviewers stop responding

[Greg KH]

On Thu, Nov 18, 2021 at 01:55:41PM -0600, Ian Pilcher wrote:
> I am looking for advice on how to proceed when kernel patch reviewers
> stop responding to patches.  I've been working on a patch series for
> several months - sending 3 "RFC" and 8 non-RFC versions, receiving
> feedback, and implementing all of the changes that have been requested.
> 
> I sent the last patch series (version 8) on October 9, and resent it on
> October 22.  I also sent an off-list email to the subsystem maintainer
> and the (previously) most active reviewer on November 8.  I haven't
> received any responses since October 8.
> 
> How should I proceed?

As the merge window is now over, please just resend the patches.
Remember maintainers can not add anything to their trees usually for the
week before, and during the 2 weeks of, the merge window, so that might
account for the delay here.

Also, just resend because things do get lost.

To help out, while waiting, why not review some patches for the same
subsystem on the mailing list to provide help for the maintainers?  That
help can go a long way in making sure your patches are reviewed.

good luck!

greg k-h

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

Re: correct source tree to make contributions to Linux thermal framework

[Greg KH]

On Tue, Nov 09, 2021 at 08:15:46PM +, Balakrishnan, Anand wrote:
> Hello Developers,
> 
> 
> At our company, we maintain an internal thermal framework patch. We are 
> exploring the option to up-stream this patch so we don't have to keep porting 
> this from one Kernel version to the other.
> 
> Thermal framework code resides here: 
> https://elixir.bootlin.com/linux/latest/source/drivers/thermal?
> 
> What is the correct source tree we should use from https://git.kernel.org/??

Use the tool, scripts/get_maintainer.pl on your patch and it will
identify the subsystem and mailing list where you need to send your
change to.

If you work off of the linux-next branch, that is a good start as that
contains a sum of all kernel maintainer's tree, as the
Documentation/process/ document explains, and is the easiest to work off
of to start with.

Hope this helps,

greg k-h

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

Re: Kernel module that shuts down the device

[Greg KH]

On Mon, Nov 08, 2021 at 02:53:37PM -0600, Drew Abbott wrote:
> > There's a whole bunch of ways to schedule work in the kernel, it doesn't
> have to be
> > a heartbeat function.
> >
> > Plenty of drivers are split into IRQ and non-IRQ parts (sometimes called
> the top and
> > bottom parts of the driver).  See how they get info from the IRQ part to
> the non-IRQ part.
> 
> I saw that this driver and others use workqueues to run longer functions
> outside of the irq handlers in the process context, so I tried scheduling a
> simple work struct that calls kernel_power_off() with this new patch:
> https://github.com/Abbotta4/linux/commit/008a720d9ffc31d5b60e0ca36f2aad0a04d50f0a
> after reading up on workqueues a bit here:
> https://linux-kernel-labs.github.io/refs/heads/master/labs/deferred_work.html#workqueues
> but the device still seems to hang at the blocking_notifier_call_chain()
> call. Is there something else I am missing here, other than leaving the irq
> context?

I do not know, I'm not going to dig around on random web sites for
patches, sorry :)

> > But step back, why would this driver ever want to shut down the machine
> > at all?  What problem are you trying to solve by making changes in this
> > driver?
> 
> This change is to help the factory team test the devices before they are
> fully assembled. There are a series of tests that they run on different
> components and being able to unplug the device to trigger a shutdown is one
> of their priorities. I hope that sheds some light on the context of these
> patches and the strange functionality I am trying to implement. Sorry if it
> caused any confusion.

Why are you trying to do this in the typec driver?  You should be able
to do all of this in userspace, just use libusb to get a list of devices
connected and when one is removed, reboot the machine.  There should not
be any need to write kernel code at all here.

Or, if you really want to write kernel code, do so for when you remove
the actual USB device itself, not in the typec code, so write a USB
driver for the USB device, not controller.

thanks,

greg k-h

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

Re: Kernel module that shuts down the device

[Greg KH]

On Sun, Nov 07, 2021 at 06:16:55PM -0600, Drew Abbott wrote:
> >  Where are you calling it from?  Don't call it from irq context, which is
> the context that USB urbs are called from.
> 
> I am currently calling it from an irq context, in the fusb302_irq_work()
> function of the in-tree fusb302.c driver. My relevant patch is below.

Ah, then do not do that :)

>  > Do you have a link to your driver code so it can be reviewed?
> 
> The relevant change is here:
> https://github.com/Abbotta4/linux/commit/fbfbb1db54d6bd1b10d56c9e86d08d0ecfe9abdc
> You mentioned that this shouldn't be called in an irq context, but the
> unplug event is detected with an irq. Where should I be calling
> kernel_power_off() if not in the irq context? I think one way of doing this
> would be to set a value that a heartbeat function reads in the irq, and
> then the heartbeat function calls the shutdown, but this driver doesn't use
> a heartbeat. Where else would I handle this?

As Vladis says, there are many many ways to do this.

But step back, why would this driver ever want to shut down the machine
at all?  What problem are you trying to solve by making changes in this
driver?

thanks,

greg k-h

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

Re: Kernel module that shuts down the device

[Greg KH]

On Sat, Nov 06, 2021 at 07:54:39PM -0500, Drew Abbott wrote:
> Hi all,
> 
> I am working on a kernel module that should shut down the device when USB
> is unplugged. I make a call to kernel_power_off(), but I see that it gets
> stuck trying to call blocking_notifier_call_chain(_notifier_list,
> (state == SYSTEM_HALT) ? SYS_HALT : SYS_POWER_OFF, NULL); in
> kernel_shutdown_prepare().

Where are you calling it from?  Don't call it from irq context, which is
the context that USB urbs are called from.

> There is currently another driver that has the same function, and shuts
> down the device by calling kernel_power_off() successfully. I have tried
> adding prints in blocking_notifier_call_chain, but then the kernel log is
> flooded with calls and I can't really see what is happening.
> Does anyone have any insight into why my call to kernel_power_off() is
> hanging?

Do you have a link to your driver code so it can be reviewed?

thanks,

greg k-h

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

Re: Any tracing mechanism can track the executed instructions of a user process in the kernel?

[Greg KH]

On Mon, Oct 18, 2021 at 04:41:14PM +0800, Dongliang Mu wrote:
> On Mon, Oct 18, 2021 at 4:07 PM FMDF  wrote:
> >
> > On Mon, 18 Oct 2021, 04:46 Dongliang Mu,  wrote:
> >>
> >> Hi all,
> >>
> >> I am writing to kindly ask one question: is there any tracing
> >> mechanism in Linux kernel that can trace all the executed instructions
> >> of a user process? If this user process is run on different
> >> processors, traces of this process on different processors should be
> >> also recorded.
> >
> >
> > You've not explained in detail what is the purpose of the tracing that you 
> > want to do. Missing this information I can only provide you a list of links 
> > to various tools and methods. Take a look by yourself and try to figure out 
> > what is better suited for your needs...
> 
> I want to log all the executed instructions of a user process (e.g.,
> poc.c in syzkaller) in the kernel mode and then would like to leverage
> backward analysis to capture the root cause of kernel panic/crash.
> 
> Therefore, I need the instruction-level tracing mechanisms or tools.

Then use a userspace debugger like gdb, that is what they are designed
for.

good luck!

greg k-h

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

Re: kernel doesn't start booting after chaning to minimum config (on qemu arm64 machine)

[Greg KH]

On Tue, Oct 12, 2021 at 11:06:53PM +0900, Chan Kim wrote:
> Hello all,
> 
> To make a minimal kernel size (with almost no driver), I copied a .config
> that was used for building kernel for sparc machine using linux 3.3 several
> years ago to current linux 5.4.21 version build tree.
> 
> (That .config was for kernel with interrupt controller, timer and uart so a
> very basic scheduling and shell is possible.)
> 
> Then I ran 
> 
> Yes "" | make ARCH=arm64 CROSS_COMPILE=aarch64-none-elf- oldconfig
> 
> This copies the configs and sets all the new config settings with default
> values. 
> 
> (see
> https://serverfault.com/questions/116299/automatically-answer-defaults-when-
> doing-make-oldconfig-on-a-kernel-tree)
> 
>  
> 
> Now I can see the start_kernel function runs to the end and it's running
> inside the cpu_idle function. but I don't see the first scrolling message
> below that I normally should see.
> 
> [0.00] Booting Linux on physical CPU 0x00 [0x410fd083]
> 
> I tried adding several CONFIG variables using menuconfig but it's still the
> same.
> 
> (CONFIG_SERIAL_AMBA_PL010, CONFIG_SERIAL_AMBA_PL010_CONSOLE,
> CONFIG_SERIAL_CORE, CONFIG_SERIAL_CORE_CONSOLE were already automatically
> set. 
> 
> And later I tried adding CONFIG_CPU_IDLE, CONFIG_CPU_IDLE_GOV_LADDR,
> CONFIG_ACPI and other ACPI related things, CONFIG_PCI_ECAM, CONFIG_PNP,
> CONFIG_PNP_DEBUG_MESSAGES, .. )
> 
> And the qemu command is like this.
> 
> ${QEMU_DIR}/qemu-system-aarch64 -M ${QMACHINE} -cpu cortex-a72 -kernel
> ${LINUX_DIR}/arch/arm64/boot/Image -initrd ${BUSYBOX_DIR}/initramfs.cpio.gz
> --append "root=/dev/ram init=/init nokaslr earlycon ip=dhcp" -m 2048M
> -nographic -netdev user,id=n1 -device e1000,netdev=n1
> 
> Has anyone any idea what I can add in the config or try? (with original
> .config, the kernel boots ok to the bash in initramfs)
> 
> Any suggestion will be appreciated.

There are two different ways of getting a "minimal" kernel
configuration:
- start with a working one and remove items until something
  breaks
- start with a minimal config and keep adding things until it
  works.

Usually the first option is the easier one, as it should go faster and
you can figure out exactly what is needed.  The second way is just
blindly guessing, like it seems you are doing here.

Best of luck!

greg k-h

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

Re: Accessing a pdev or its members

[Greg KH]

On Fri, Sep 24, 2021 at 09:30:55PM -0500, Drew Abbott wrote:
> Hello all,
> 
> A third party driver has a probe function foo_probe(struct
> platform_device) that ends up allocating and initializing a list of
> various device structs:
> 
> struct device *dev = >dev;
> struct ucsi_dev *udev;
> udev = devm_kzalloc(dev, sizeof(*udev), GFP_KERNEL);
> /* initialize udev to important data */
> platform_set_drvdata(pdev, udev);
> 
> I have my own driver that I would like to use to access the *udev that
> is created when the other device is probed. How would I access a pdev?

You can not, it is not owned by your driver and the lifetime rules
should not give you access to it.

Why would you want to poke around in a platform device that is
controlled by a different driver?  What does your driver want to do?

> Or is there a way I can add a function to this driver to expose a
> *udev? I can't seem to get to it without having a pointer to the pdev,
> the udev, or some other device struct related to the hardware.

Why not move your functionality into the existing driver if you need to
talk to the same hardware device?

thanks,

greg k-h

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

Re: List of all available kernel modules per version

[Greg KH]

On Thu, Sep 23, 2021 at 07:55:45PM +0200, Leon Gross wrote:
> 
> > A:http://en.wikipedia.org/wiki/Top_post
> > Q: Were do I find info about this thing called top-posting?
> > A: Because it messes up the order in which people normally read text.
> > Q: Why is top-posting such a bad thing?
> > A: Top-posting.
> > Q: What is the most annoying thing in e-mail?
> > 
> > A: No.
> > Q: Should I include quotations after my reply?
> > 
> > http://daringfireball.net/2007/07/on_top
> Alright, nice annotation, thanks.
> 
> > But how are you mapping a module "name" to what it does?
> modprobe [modulename] , i thought that was how a module is mapped to a name?
> Or do you mean something different?

I mean how do you know what a module named "option" does?  What does a
list of random module names show you?

> > Why does that matter?
> 
> It matters because if I have a problem to solve and I know the kernel module
> that is required to do that (like nvme_tcp) then I can narrow down which
> kernel to use.

Ok, that's different, so if you know a specific kernel module works for
a specific thing, then just look in the git tree for when that
module/driver was added to the tree.  No need to build all kernels to
find that out.

For example, to see where the nvme_tcp module was added, you can do:

$ git log --oneline drivers/nvme/host/tcp.c | tail -n 1
3f2304f8c6d6 nvme-tcp: add NVMe over TCP host driver
$ git describe --contains 3f2304f8c6d6
v5.0-rc1~52^2~57^2~20

So that showed up in the 5.0 kernel release.

Hope this helps,

greg k-h

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

Re: List of all available kernel modules per version

[Greg KH]

A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

On Thu, Sep 23, 2021 at 07:32:40PM +0200, Leon Gross wrote:
> The first thing I am interested in a complete list of all kernel modules of
> the x86 plattform for any kernel version.

Which x86 platform?  There are many different ones.

> The problem I want to solve is a generalized way to find out the kernel
> versions in which modules first were supported.

But how are you mapping a module "name" to what it does?

Why does that matter?

> One exmaple is the `nvme_tcp` module. Trough testing on machines running
> different kernels and stackoverflow articles
> I figured out that it might have been supported since kernel version 5.x. I
> would like to have a way to verfiy such kind of
> information for any given module.

Do a 'make allmodconfig' build for every major release and sort the
output.  Should be pretty easy to script if you really need this.

Good luck!

greg k-h

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

Re: List of all available kernel modules per version

[Greg KH]

On Thu, Sep 23, 2021 at 06:39:22PM +0200, Leon Gross wrote:
> Hi everyone,
> 
> If got more of a general question: Is there a way to list all the standard
> kernel modules that are included in a specific kernel version?

What do you mean by "standard" exactly?

What architecture?  What types of hardware do you feel are "standard"?

> And I don't meant the currently running modules I could get via lsmod but I
> mean all the modules that are supported by a specific kernel version.
> Or can I even derive these myself from the source tree, without even
> compiling the kernel (that would be very helpful)?

A random list of module names probably does not help much (hint, what
hardware does the module that is called "option.ko" support?")

What problem are you trying to solve here?

thanks,

greg k-h

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

Re: efivars

[Greg KH]

On Thu, Sep 23, 2021 at 08:24:10AM -0400, Ruben Safir wrote:
> On 9/23/21 3:27 AM, FMDF wrote:
> > but it still needs to use UEFI at runtime.
> no if it is on a bios system

If you are using the old "BIOS" interface, there are still places where
that BIOS takes over control from the CPU and does things behind the
operating system's back.  There are also things that the BIOS does that
the operating system must talk to over time in order to coordinate
things like power management and "simple" things like powering off the
system (hint, that's not a simple thing).

So your old BIOS was still sitting there running and providing services
to the operating system just like UEFI does so today.  That has not
changed except that a number of the issues involved with that old
interface have been fixed up, and a number of new interfaces have been
added.

greg k-h

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

Re: efivars

[Greg KH]

On Thu, Sep 23, 2021 at 05:56:43AM -0400, Ruben Safir wrote:
> On Wed, Sep 22, 2021 at 06:07:49PM +0200, Greg KH wrote:
> > If you don't like this, wonderful, use a system based on a different
> > type of bootloader.  But in the end, they end up all having to do the
> > same thing somehow :)
> > 
> > > All I want the boot loader to do is fine the kernel and run it.
> > 
> > Your bootloader also has to do a lot more things (initialize hardware,
> > provide information to the OS as to what hardware is present, do
> > system-level things like suspend/resume, etc.)
> > 
> 
> Why does it need the bootloader to do any of that.  It just needs to
> bring up enough hardware to find the kernel and read it... STDIO, STDOUT
> and the hard drive, assuming it is not a network boot.  The hardware's
> firmware has to initialize so minimal subset of hardware, but that has 
> nothing to do specifically with UEFI.

Define "minimal" please.  What about your RAM?  Your north/south bridge
and the i/o controllers there?  Your processor init sequence?  Find the
boot disk to start with?  How do you tell the bootloader _where_ the
boot disk is?

> Since when does the OS not control all the hardware on the system?

For x86 systems, since i486 days.  Again, remember APM?

> What you seem to be saying is that the UEFI shell is running
> simutanously to the OS, and controls hardware.

No, not at all, the "shell" is not running, but parts of it are running
and are called by the OS to do things.  Sometimes those things wake up
the OS and tell it to do things.

> That is all news to me.
> It doesn't happen in BIOS mode or systems that are still BIOS, dieing
> breed that that is.

Yes, it happened in much worse ways in the "old style BIOS" modes and
systems.  Now it is documented and unified and works much better than
ever before.

Yes, it is more "complex" than before, but you are using a much more
complex system than you used to have as well.

thanks,

greg k-h

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

Re: efivars

[Greg KH]

On Thu, Sep 23, 2021 at 05:38:27AM -0400, Ruben Safir wrote:
> > Instead the OS needs UEFI runtime services to talk to the platform
> > firmware. 
> 
> What is that?  The kernel is on the Metal.  It is talking directly to
> the hardware.

No it is not.  It is turtles all the way down, sorry.

> > (obviously there is much more than simply
> > shutting down). How can an OS know that you've attached a plug and play
> > device if it cannot talk to the platform firmware?
> > 
> What are you talking about?  The Kernel doesn't need UEFI to know a
> device is attached and to autoload a kernel module and talk to it.

Yes it does.

> It causes an interupt and announces itself on the systembus.

What do you mean exactly by "systembus"?  I have never heard of such a
thing.

> What do you think those thousands of hardware choices are about when you 
> compile the kernel?

Those are options that the kernel can enable/disable support for and
have nothing to do with how the kernel can find those devices in the
system.

> BIOS systems can do that 100%.

As I stated before, UEFI is just the newer standard of BIOS.

> And then there is other hardware, like
> ARM.

UEFI runs on many ARM systems.

Those that do not use UEFI rely on device trees to get information for
what the system looks like and how to talk to it.  x86 systems do not
use device tree, sorry.

> It is useless to for me to argue what I would want to have happen.  I
> have no say and nobody cares about my opinion.  I do want to know what
> it is doing, though, and why I can't install a UEFI boot system from a
> thumdrive that loads in BIOS mode.

Because those are two different standards.

greg k-h

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