October 2024 - kernelnewbies@kernelnewbies.org

Abandoned patch
by Patryk Dec. 19, 2024

Dec. 19, 2024

Hi, I've got a question - what can I do with a patch that was submitted some time ago (about a year ago) but after the review was abandoned by the author for no obvious reason? Perhaps, the author did not have time to finalize upstream and started working on something else. Can I take such a patch, clean up according to the comments and send it again? If so, how can I provide / retain the information about the original patch author? This patch still seems to be useful as it adds the support for a device that is still in production. Moreover, I will probably need this patch in my project. Will be grateful for some advice. Best regards Patryk

2 1

Criteria for contributing to /samples directory?
by Ann Yun Oct. 31, 2024

Oct. 31, 2024

Hi Community, My understanding is that /samples directory is where example or demonstrative code lives, but I was wondering if only the authors of kernel source code are allowed to contribute, or if the sample code has to be of certain complexity, etc. I have been experimenting with a proc filesystem driver and would love to share my learning with others who need some example code to look at. Would this be a good candidate to be in /samples? Thank you, Ann

1 0

Intel® Thread Director
by Mina G Oct. 28, 2024

Oct. 28, 2024

hello i wanted to ask about Intel® Thread Director support status in Linux kernel i know it's supported but i can't find any benchmarks or compression to it's performance on windows. and is it allow all the control on P and E cores meaning that if i want to make sure that a certain application is ruining on P cores for example could i do that Sorry for my bad English Mina

1 0

Assistance Needed for Kernel mode driver Soft Lockup Issue
by Muni Sekhar Oct. 20, 2024

Oct. 20, 2024

Dear Linux Kernel Developers, I am encountering a soft lockup issue in my system related to the continuous while loop in the empty_rx_fifo() function. Below is the relevant code: #include <linux/io.h> // For readw() #define FIFO_STATUS 0x0014 #define FIFO_MAN_READ 0x0015 #define RX_FIFO_EMPTY 0x01 // Assuming RX_FIFO_EMPTY is defined as 0x01 static inline uint16_t read16_shifted(void __iomem *addr, u32 offset) { void __iomem *target_addr = addr + (offset << 1); // Left shift the offset by 1 and add to the base address uint16_t value = readw(target_addr); // Read the 16-bit value from the calculated address return value; } void empty_rx_fifo(void __iomem *addr) { while (!(read16_shifted(addr, FIFO_STATUS) & RX_FIFO_EMPTY)) { read16_shifted(addr, FIFO_MAN_READ); // Keep reading from the FIFO until it's empty } } Explanation: Function Name: read16_shifted — The function reads a 16-bit value from an offset address with a left shift operation. Operation: It shifts the offset left by 1 (offset << 1), adds it to the base address, and reads the value from the new address. The empty_rx_fifo function is designed to clear out the RX FIFO, but I've encountered soft lockup issues. Specifically, the system logs repeated soft lockup messages in the kernel log, with a time gap of roughly 28 seconds between them (as per the kernel log timestamps). Here's an example log: watchdog: BUG: soft lockup - CPU#0 stuck for 23s! In all cases, the RIP points to: RIP: 0010:read16_shifted+0x11/0x20 Analysis: The soft lockup seems to be caused by the continuous while loop in the empty_rx_fifo() function. The RX FIFO takes a considerable amount of time to empty, sometimes up to 1000 seconds. As a result, from the first occurrence of the soft lockup trace, the log repeats approximately every 28 seconds for the entire 1000 seconds duration. After 1000 seconds, the system resumes normal operation. Questions: 1. How should I best handle this kind of issue? Even if the hardware takes time, I would like advice on the best approach to prevent these lockups. 2. Do soft lockup issues auto-recover like this? Is this something I should consider serious, or can it be ignored? I would appreciate any guidance on how to resolve or mitigate this problem. -- Thanks, Sekhar

4 4

Problem using git send-email with yahoo and hotmail
by Manuel Quintero F Oct. 4, 2024

Oct. 4, 2024

Hello, I would like to use Yahoo to send patches via git send-email, but I get the following error: "5.7.0 (#AUTH005) Too many bad auth attempts." I have the following configuration: [sendemail] smtpEncryption = ssl smtpServer = smtp.mail.yahoo.com smtpUser = sakunix(a)yahoo.com smtpServerPort = 465 The error with hotmail is the following: Password for 'smtp://sakunix@hotmail.com@smtp-mail.outlook.com:587': 5.7.139 Authentication unsuccessful, basic authentication is disabled. [SA9PR03CA0003.namprd03.prod.outlook.com 2024-10-03T22:12:28.938Z 08DCE3B2AADBD951] Note: I don't know the reason, but my first test with hotmail did send the patch.

2 2

Re: Contributing to linux kernel
by Philipp Hortmann Oct. 3, 2024

Oct. 3, 2024

On 10/3/24 10:21, ömer bulut wrote: > Hi Philip, > > Thanks for your quick reply. I just love it how this community works. > Actually i look to kernelnewbie web page previously. I also watch gregs > youtube videos ( https://www.youtube.com/watch?v=LLBrBBImJt4&t=414s ) and > i read some books that recommended on stackoverflow or kernel web site - i > just keep reading those books. I want to going to look into some drivers to > find out little bugs. > Are you maintainers for any drivers that i can look into it? Maybe it could > be good start point. > > Best Regards... > Ömer > > Philipp Hortmann <philipp.g.hortmann(a)gmail.com>, 2 Eki 2024 Çar, 21:06 > tarihinde şunu yazdı: > >> On 10/2/24 16:57, ömer bulut wrote: >>> Hi, >>> >>> I have spent almost 10 years for writing device drivers so i want to >>> contribute to linux kernel. There are some pmic drivers from Texas >>> Instruments like bq24190 etc in the linux source tree. Would writing >>> driver for bq25120a be helpful or should i begin with bit little like >>> fixing some coverity bugs? >>> >>> Best Regards... >>> >>> >>> _______________________________________________ >>> Kernelnewbies mailing list >>> Kernelnewbies(a)kernelnewbies.org >>> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> >> Hi Ömer, >> >> great that you have so much experience. I recommend you start with the >> homepage: >> >> https://kernelnewbies.org/ >> Go complete our tutorial for creating your first kernel patch... >> >> I recommend to start with really simple patches with only some changes. >> Nobody is mad when you just change one place on your first patch. Then >> you need to be patient. As the response can take some time. You can use >> this time to prepare for the next but typically it is not wise to send >> in multiple patches with the same issue. So start simple and evolve... >> >> In case of questions feel free to write again. >> >> Thanks for your support. >> >> Bye Philipp >> >> >> > Hi Ömer, please do not use top posting for kernel mailing lists. I also recommend to read in the subsystem mailing list: https://lore.kernel.org/linux-staging/ I am not Maintainer. I am trying to support the maintainer Greg Kroah-Hartman. As I managed to buy hardware for: rtl8192e rtl8712 rtl8723bs vt6656 I am typically responding to those Patches. We had a two week merge window until last Sunday. All patches in the Que have not been added by the maintainer. So sending in patches can conflict with other patches send in earlier. You have three choices... wait until the patches get in or apply the patches relevant to the driver you want to work on or change only files for which no patches are relevant. As a first starting point I recommend to remove some unused macros in rtl8192e. Please check if this macros are used and remove all unused ones. #define rPMAC_Reset 0x100 #define rPMAC_TxStart 0x104 #define rPMAC_TxLegacySIG 0x108 #define rPMAC_TxHTSIG1 0x10c #define rPMAC_TxHTSIG2 0x110 #define rPMAC_PHYDebug 0x114 #define rPMAC_TxPacketNum 0x118 #define rPMAC_TxIdle 0x11c #define rPMAC_TxMACHeader0 0x120 #define rPMAC_TxMACHeader1 0x124 #define rPMAC_TxMACHeader2 0x128 #define rPMAC_TxMACHeader3 0x12c #define rPMAC_TxMACHeader4 0x130 #define rPMAC_TxMACHeader5 0x134 #define rPMAC_TxDataType 0x138 #define rPMAC_TxRandomSeed 0x13c #define rPMAC_CCKPLCPPreamble 0x140 #define rPMAC_CCKPLCPHeader 0x144 #define rPMAC_CCKCRC16 0x148 #define rPMAC_OFDMRxCRC32OK 0x170 #define rPMAC_OFDMRxCRC32Er 0x174 #define rPMAC_OFDMRxParityEr 0x178 #define rPMAC_OFDMRxCRC8Er 0x17c #define rPMAC_CCKCRxRC16Er 0x180 #define rPMAC_CCKCRxRC32Er 0x184 #define rPMAC_CCKCRxRC32OK 0x188 #define rPMAC_TxStatus 0x18c You can take the description from old patches in git. Make your Subject line unique by adding the first removed macro. Thanks for your support. Bye Philipp

1 0

Contributing to linux kernel
by ömer bulut Oct. 2, 2024

Oct. 2, 2024

Hi, I have spent almost 10 years for writing device drivers so i want to contribute to linux kernel. There are some pmic drivers from Texas Instruments like bq24190 etc in the linux source tree. Would writing driver for bq25120a be helpful or should i begin with bit little like fixing some coverity bugs? Best Regards...

2 1