Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

performance fix #470

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

performance fix #470

wants to merge 1 commit into from

Conversation

ghost
Copy link

@ghost ghost commented Sep 26, 2017

change for -> while

change for -> while
@KernelPRBot
Copy link

Hi @parduscix!

Thanks for your contribution to the Linux kernel!

Linux kernel development happens on mailing lists, rather than on GitHub - this GitHub repository is a read-only mirror that isn't used for accepting contributions. So that your change can become part of Linux, please email it to us as a patch.

Sending patches isn't quite as simple as sending a pull request, but fortunately it is a well documented process.

Here's what to do:

  • Format your contribution according to kernel requirements
  • Decide who to send your contribution to
  • Set up your system to send your contribution as an email
  • Send your contribution and wait for feedback

How do I format my contribution?

The Linux kernel community is notoriously picky about how contributions are formatted and sent. Fortunately, they have documented their expectations.

Firstly, all contributions need to be formatted as patches. A patch is a plain text document showing the change you want to make to the code, and documenting why it is a good idea.

You can create patches with git format-patch.

Secondly, patches need 'commit messages', which is the human-friendly documentation explaining what the change is and why it's necessary.

Thirdly, changes have some technical requirements. There is a Linux kernel coding style, and there are licensing requirements you need to comply with.

Both of these are documented in the Submitting Patches documentation that is part of the kernel.

Note that you will almost certainly have to modify your existing git commits to satisfy these requirements. Don't worry: there are many guides on the internet for doing this.

Who do I send my contribution to?

The Linux kernel is composed of a number of subsystems. These subsystems are maintained by different people, and have different mailing lists where they discuss proposed changes.

If you don't already know what subsystem your change belongs to, the get_maintainer.pl script in the kernel source can help you.

get_maintainer.pl will take the patch or patches you created in the previous step, and tell you who is responsible for them, and what mailing lists are used. You can also take a look at the MAINTAINERS file by hand.

Make sure that your list of recipients includes a mailing list. If you can't find a more specific mailing list, then LKML - the Linux Kernel Mailing List - is the place to send your patches.

It's not usually necessary to subscribe to the mailing list before you send the patches, but if you're interested in kernel development, subscribing to a subsystem mailing list is a good idea. (At this point, you probably don't need to subscribe to LKML - it is a very high traffic list with about a thousand messages per day, which is often not useful for beginners.)

How do I send my contribution?

Use git send-email, which will ensure that your patches are formatted in the standard manner. In order to use git send-email, you'll need to configure git to use your SMTP email server.

For more information about using git send-email, look at the Git documentation or type git help send-email. There are a number of useful guides and tutorials about git send-email that can be found on the internet.

How do I get help if I'm stuck?

Firstly, don't get discouraged! There are an enormous number of resources on the internet, and many kernel developers who would like to see you succeed.

Many issues - especially about how to use certain tools - can be resolved by using your favourite internet search engine.

If you can't find an answer, there are a few places you can turn:

  • Kernel Newbies - this website contains a lot of useful resources for new kernel developers.
  • If you'd like a step-by-step, challenge-based introduction to kernel development, the Eudyptula Challenge would be an excellent start.
  • The kernel documentation - see also the Documentation directory in the kernel tree.

If you get really, really stuck, you could try the owners of this bot, @daxtens and @ajdlinux. Please be aware that we do have full-time jobs, so we are almost certainly the slowest way to get answers!

I sent my patch - now what?

You wait.

You can check that your email has been received by checking the mailing list archives for the mailing list you sent your patch to. Messages may not be received instantly, so be patient. Kernel developers are generally very busy people, so it may take a few weeks before your patch is looked at.

Then, you keep waiting. Three things may happen:

  • You might get a response to your email. Often these will be comments, which may require you to make changes to your patch, or explain why your way is the best way. You should respond to these comments, and you may need to submit another revision of your patch to address the issues raised.
  • Your patch might be merged into the subsystem tree. Code that becomes part of Linux isn't merged into the main repository straight away - it first goes into the subsystem tree, which is managed by the subsystem maintainer. It is then batched up with a number of other changes sent to Linus for inclusion. (This process is described in some detail in the kernel development process guide).
  • Your patch might be ignored completely. This happens sometimes - don't take it personally. Here's what to do:
    • Wait a bit more - patches often take several weeks to get a response; more if they were sent at a busy time.
    • Kernel developers often silently ignore patches that break the rules. Check for obvious violations of the the Submitting Patches guidelines, the style guidelines, and any other documentation you can find about your subsystem. Check that you're sending your patch to the right place.
    • Try again later. When you resend it, don't add angry commentary, as that will get your patch ignored. It might also get you silently blacklisted.

Further information

Happy hacking!

This message was posted by a bot - if you have any questions or suggestions, please talk to my owners, @ajdlinux and @daxtens, or raise an issue at https://github.com/ajdlinux/KernelPRBot.

@@ -267,7 +267,9 @@ static int __init set_init_arg(char *param, char *val,

repair_env_string(param, val, unused, NULL);

for (i = 0; argv_init[i]; i++) {
i = 0;
while(argv_init[i]){

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why change while

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any special gain?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also on first iteration i = 1 not 0 as it is with the for

@klingtnet
Copy link

Now I know why the kernel development happens in mailing lists, this performance fix is a joke, right?

@mrnirva
Copy link

mrnirva commented Nov 3, 2017

I agree with you

@alexozer
Copy link

alexozer commented Nov 7, 2017

What the debate about, this seems pretty serious to me? It's a simple change for a simple improvement.

for (i = 0; argv_init[i]; i++) {
i = 0;
while(argv_init[i]){
i++;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This skips i = 0, I believe.

metux added a commit to metux/linux that referenced this pull request Apr 27, 2019
Fix checkpatch warnings:

    WARNING: Use #include <linux/io.h> instead of <asm/io.h>
    torvalds#38: FILE: drivers/tty/serial/sunzilog.c:38:
    +#include <asm/io.h>

    WARNING: line over 80 characters
    torvalds#109: FILE: drivers/tty/serial/sunzilog.c:109:
    +#define ZILOG_CHANNEL_FROM_PORT(PORT)	((struct zilog_channel __iomem *)((PORT)->membase))

    WARNING: line over 80 characters
    torvalds#116: FILE: drivers/tty/serial/sunzilog.c:116:
    +#define ZS_WANTS_MODEM_STATUS(UP)	((UP)->flags & SUNZILOG_FLAG_MODEM_STATUS)

    WARNING: line over 80 characters
    torvalds#179: FILE: drivers/tty/serial/sunzilog.c:179:
    +static int __load_zsregs(struct zilog_channel __iomem *channel, unsigned char *regs)

    WARNING: Missing a blank line after declarations
    torvalds#188: FILE: drivers/tty/serial/sunzilog.c:188:
    +		unsigned char stat = read_zsreg(channel, R1);
    +		if (stat & ALL_SNT)

    ERROR: trailing whitespace
    torvalds#231: FILE: drivers/tty/serial/sunzilog.c:231:
    +^I$

    WARNING: braces {} are not necessary for any arm of this statement
    torvalds#276: FILE: drivers/tty/serial/sunzilog.c:276:
    +		if (ZS_TX_ACTIVE(up)) {
    [...]
    +		} else {
    [...]

    ERROR: else should follow close brace '}'
    torvalds#378: FILE: drivers/tty/serial/sunzilog.c:378:
    +			}
    +			else if (r1 & PAR_ERR)

    ERROR: code indent should use tabs where possible
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: please, no space before tabs
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: line over 80 characters
    torvalds#440: FILE: drivers/tty/serial/sunzilog.c:440:
    +		/* The Zilog just gives us an interrupt when DCD/CTS/etc. change.

    WARNING: line over 80 characters
    torvalds#441: FILE: drivers/tty/serial/sunzilog.c:441:
    +		 * But it does not tell us which bit has changed, we have to keep

    WARNING: Missing a blank line after declarations
    torvalds#464: FILE: drivers/tty/serial/sunzilog.c:464:
    +		unsigned char status = readb(&channel->control);
    +		ZSDELAY();

    WARNING: line over 80 characters
    torvalds#468: FILE: drivers/tty/serial/sunzilog.c:468:
    +		 * It can occur because of how we do serial console writes.  It would

    WARNING: line over 80 characters
    torvalds#469: FILE: drivers/tty/serial/sunzilog.c:469:
    +		 * be nice to transmit console writes just like we normally would for

    WARNING: line over 80 characters
    torvalds#470: FILE: drivers/tty/serial/sunzilog.c:470:
    +		 * a TTY line. (ie. buffered and TX interrupt driven).  That is not

    WARNING: line over 80 characters
    torvalds#471: FILE: drivers/tty/serial/sunzilog.c:471:
    +		 * easy because console writes cannot sleep.  One solution might be

    WARNING: line over 80 characters
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    WARNING: plain inline is preferred over __inline__
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    ERROR: trailing whitespace
    torvalds#664: FILE: drivers/tty/serial/sunzilog.c:664:
    +^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#752: FILE: drivers/tty/serial/sunzilog.c:752:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#779: FILE: drivers/tty/serial/sunzilog.c:779:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    WARNING: line over 80 characters
    #999: FILE: drivers/tty/serial/sunzilog.c:999:
    +static int sunzilog_verify_port(struct uart_port *port, struct serial_struct *ser)

    WARNING: Missing a blank line after declarations
    #1142: FILE: drivers/tty/serial/sunzilog.c:1142:
    +		unsigned char val = readb(&channel->control);
    +		if (val & Tx_BUF_EMP) {

    WARNING: Prefer [subsystem eg: netdev]_info([subsystem]dev, ... then dev_info(dev, ... then pr_info(...  to printk(KERN_INFO ...
    #1230: FILE: drivers/tty/serial/sunzilog.c:1230:
    +	printk(KERN_INFO "Console: ttyS%d (SunZilog zs%d)\n",

    WARNING: braces {} are not necessary for single statement blocks
    #1383: FILE: drivers/tty/serial/sunzilog.c:1383:
    +		if (__load_zsregs(channel, up->curregs)) {
    +			up->flags |= SUNZILOG_FLAG_ESCC;
    +		}

    WARNING: quoted string split across lines
    #1493: FILE: drivers/tty/serial/sunzilog.c:1493:
    +		dev_info(&op->dev, "Keyboard at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: quoted string split across lines
    #1497: FILE: drivers/tty/serial/sunzilog.c:1497:
    +		dev_info(&op->dev, "Mouse at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: Missing a blank line after declarations
    #1581: FILE: drivers/tty/serial/sunzilog.c:1581:
    +		struct uart_sunzilog_port *up = sunzilog_irq_chain;
    +		err = request_irq(zilog_irq, sunzilog_interrupt, IRQF_SHARED,

    WARNING: line over 80 characters
    #1590: FILE: drivers/tty/serial/sunzilog.c:1590:
    +			/* printk (KERN_INFO "Enable IRQ for ZILOG Hardware %p\n", up); */

    WARNING: line over 80 characters
    #1627: FILE: drivers/tty/serial/sunzilog.c:1627:
    +			/* printk (KERN_INFO "Disable IRQ for ZILOG Hardware %p\n", up); */

    ERROR: trailing statements should be on next line
    #1248: FILE: drivers/tty/serial/sunzilog.c:1248:
    +	case B150: baud = 150; break;

    ERROR: trailing statements should be on next line
    #1249: FILE: drivers/tty/serial/sunzilog.c:1249:
    +	case B300: baud = 300; break;

    ERROR: trailing statements should be on next line
    #1250: FILE: drivers/tty/serial/sunzilog.c:1250:
    +	case B600: baud = 600; break;

    ERROR: trailing statements should be on next line
    #1251: FILE: drivers/tty/serial/sunzilog.c:1251:
    +	case B1200: baud = 1200; break;

    ERROR: trailing statements should be on next line
    #1252: FILE: drivers/tty/serial/sunzilog.c:1252:
    +	case B2400: baud = 2400; break;

    ERROR: trailing statements should be on next line
    #1253: FILE: drivers/tty/serial/sunzilog.c:1253:
    +	case B4800: baud = 4800; break;

    ERROR: trailing statements should be on next line
    #1254: FILE: drivers/tty/serial/sunzilog.c:1254:
    +	default: case B9600: baud = 9600; break;

    ERROR: trailing statements should be on next line
    #1255: FILE: drivers/tty/serial/sunzilog.c:1255:
    +	case B19200: baud = 19200; break;

    ERROR: trailing statements should be on next line
    #1256: FILE: drivers/tty/serial/sunzilog.c:1256:
    +	case B38400: baud = 38400; break;

Signed-off-by: Enrico Weigelt <info@metux.net>
metux added a commit to metux/linux that referenced this pull request Apr 29, 2019
Fix checkpatch warnings:

    WARNING: Use #include <linux/io.h> instead of <asm/io.h>
    torvalds#38: FILE: drivers/tty/serial/sunzilog.c:38:
    +#include <asm/io.h>

    WARNING: line over 80 characters
    torvalds#109: FILE: drivers/tty/serial/sunzilog.c:109:
    +#define ZILOG_CHANNEL_FROM_PORT(PORT)	((struct zilog_channel __iomem *)((PORT)->membase))

    WARNING: line over 80 characters
    torvalds#116: FILE: drivers/tty/serial/sunzilog.c:116:
    +#define ZS_WANTS_MODEM_STATUS(UP)	((UP)->flags & SUNZILOG_FLAG_MODEM_STATUS)

    WARNING: line over 80 characters
    torvalds#179: FILE: drivers/tty/serial/sunzilog.c:179:
    +static int __load_zsregs(struct zilog_channel __iomem *channel, unsigned char *regs)

    WARNING: Missing a blank line after declarations
    torvalds#188: FILE: drivers/tty/serial/sunzilog.c:188:
    +		unsigned char stat = read_zsreg(channel, R1);
    +		if (stat & ALL_SNT)

    ERROR: trailing whitespace
    torvalds#231: FILE: drivers/tty/serial/sunzilog.c:231:
    +^I$

    WARNING: braces {} are not necessary for any arm of this statement
    torvalds#276: FILE: drivers/tty/serial/sunzilog.c:276:
    +		if (ZS_TX_ACTIVE(up)) {
    [...]
    +		} else {
    [...]

    ERROR: else should follow close brace '}'
    torvalds#378: FILE: drivers/tty/serial/sunzilog.c:378:
    +			}
    +			else if (r1 & PAR_ERR)

    ERROR: code indent should use tabs where possible
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: please, no space before tabs
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: line over 80 characters
    torvalds#440: FILE: drivers/tty/serial/sunzilog.c:440:
    +		/* The Zilog just gives us an interrupt when DCD/CTS/etc. change.

    WARNING: line over 80 characters
    torvalds#441: FILE: drivers/tty/serial/sunzilog.c:441:
    +		 * But it does not tell us which bit has changed, we have to keep

    WARNING: Missing a blank line after declarations
    torvalds#464: FILE: drivers/tty/serial/sunzilog.c:464:
    +		unsigned char status = readb(&channel->control);
    +		ZSDELAY();

    WARNING: line over 80 characters
    torvalds#468: FILE: drivers/tty/serial/sunzilog.c:468:
    +		 * It can occur because of how we do serial console writes.  It would

    WARNING: line over 80 characters
    torvalds#469: FILE: drivers/tty/serial/sunzilog.c:469:
    +		 * be nice to transmit console writes just like we normally would for

    WARNING: line over 80 characters
    torvalds#470: FILE: drivers/tty/serial/sunzilog.c:470:
    +		 * a TTY line. (ie. buffered and TX interrupt driven).  That is not

    WARNING: line over 80 characters
    torvalds#471: FILE: drivers/tty/serial/sunzilog.c:471:
    +		 * easy because console writes cannot sleep.  One solution might be

    WARNING: line over 80 characters
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    WARNING: plain inline is preferred over __inline__
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    ERROR: trailing whitespace
    torvalds#664: FILE: drivers/tty/serial/sunzilog.c:664:
    +^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#752: FILE: drivers/tty/serial/sunzilog.c:752:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#779: FILE: drivers/tty/serial/sunzilog.c:779:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    WARNING: line over 80 characters
    #999: FILE: drivers/tty/serial/sunzilog.c:999:
    +static int sunzilog_verify_port(struct uart_port *port, struct serial_struct *ser)

    WARNING: Missing a blank line after declarations
    #1142: FILE: drivers/tty/serial/sunzilog.c:1142:
    +		unsigned char val = readb(&channel->control);
    +		if (val & Tx_BUF_EMP) {

    WARNING: Prefer [subsystem eg: netdev]_info([subsystem]dev, ... then dev_info(dev, ... then pr_info(...  to printk(KERN_INFO ...
    #1230: FILE: drivers/tty/serial/sunzilog.c:1230:
    +	printk(KERN_INFO "Console: ttyS%d (SunZilog zs%d)\n",

    WARNING: braces {} are not necessary for single statement blocks
    #1383: FILE: drivers/tty/serial/sunzilog.c:1383:
    +		if (__load_zsregs(channel, up->curregs)) {
    +			up->flags |= SUNZILOG_FLAG_ESCC;
    +		}

    WARNING: quoted string split across lines
    #1493: FILE: drivers/tty/serial/sunzilog.c:1493:
    +		dev_info(&op->dev, "Keyboard at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: quoted string split across lines
    #1497: FILE: drivers/tty/serial/sunzilog.c:1497:
    +		dev_info(&op->dev, "Mouse at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: Missing a blank line after declarations
    #1581: FILE: drivers/tty/serial/sunzilog.c:1581:
    +		struct uart_sunzilog_port *up = sunzilog_irq_chain;
    +		err = request_irq(zilog_irq, sunzilog_interrupt, IRQF_SHARED,

    WARNING: line over 80 characters
    #1590: FILE: drivers/tty/serial/sunzilog.c:1590:
    +			/* printk (KERN_INFO "Enable IRQ for ZILOG Hardware %p\n", up); */

    WARNING: line over 80 characters
    #1627: FILE: drivers/tty/serial/sunzilog.c:1627:
    +			/* printk (KERN_INFO "Disable IRQ for ZILOG Hardware %p\n", up); */

    ERROR: trailing statements should be on next line
    #1248: FILE: drivers/tty/serial/sunzilog.c:1248:
    +	case B150: baud = 150; break;

    ERROR: trailing statements should be on next line
    #1249: FILE: drivers/tty/serial/sunzilog.c:1249:
    +	case B300: baud = 300; break;

    ERROR: trailing statements should be on next line
    #1250: FILE: drivers/tty/serial/sunzilog.c:1250:
    +	case B600: baud = 600; break;

    ERROR: trailing statements should be on next line
    #1251: FILE: drivers/tty/serial/sunzilog.c:1251:
    +	case B1200: baud = 1200; break;

    ERROR: trailing statements should be on next line
    #1252: FILE: drivers/tty/serial/sunzilog.c:1252:
    +	case B2400: baud = 2400; break;

    ERROR: trailing statements should be on next line
    #1253: FILE: drivers/tty/serial/sunzilog.c:1253:
    +	case B4800: baud = 4800; break;

    ERROR: trailing statements should be on next line
    #1254: FILE: drivers/tty/serial/sunzilog.c:1254:
    +	default: case B9600: baud = 9600; break;

    ERROR: trailing statements should be on next line
    #1255: FILE: drivers/tty/serial/sunzilog.c:1255:
    +	case B19200: baud = 19200; break;

    ERROR: trailing statements should be on next line
    #1256: FILE: drivers/tty/serial/sunzilog.c:1256:
    +	case B38400: baud = 38400; break;

Signed-off-by: Enrico Weigelt <info@metux.net>
metux added a commit to metux/linux that referenced this pull request Apr 30, 2019
Fix checkpatch warnings:

    WARNING: Use #include <linux/io.h> instead of <asm/io.h>
    torvalds#38: FILE: drivers/tty/serial/sunzilog.c:38:
    +#include <asm/io.h>

    WARNING: line over 80 characters
    torvalds#109: FILE: drivers/tty/serial/sunzilog.c:109:
    +#define ZILOG_CHANNEL_FROM_PORT(PORT)	((struct zilog_channel __iomem *)((PORT)->membase))

    WARNING: line over 80 characters
    torvalds#116: FILE: drivers/tty/serial/sunzilog.c:116:
    +#define ZS_WANTS_MODEM_STATUS(UP)	((UP)->flags & SUNZILOG_FLAG_MODEM_STATUS)

    WARNING: line over 80 characters
    torvalds#179: FILE: drivers/tty/serial/sunzilog.c:179:
    +static int __load_zsregs(struct zilog_channel __iomem *channel, unsigned char *regs)

    WARNING: Missing a blank line after declarations
    torvalds#188: FILE: drivers/tty/serial/sunzilog.c:188:
    +		unsigned char stat = read_zsreg(channel, R1);
    +		if (stat & ALL_SNT)

    ERROR: trailing whitespace
    torvalds#231: FILE: drivers/tty/serial/sunzilog.c:231:
    +^I$

    WARNING: braces {} are not necessary for any arm of this statement
    torvalds#276: FILE: drivers/tty/serial/sunzilog.c:276:
    +		if (ZS_TX_ACTIVE(up)) {
    [...]
    +		} else {
    [...]

    ERROR: else should follow close brace '}'
    torvalds#378: FILE: drivers/tty/serial/sunzilog.c:378:
    +			}
    +			else if (r1 & PAR_ERR)

    ERROR: code indent should use tabs where possible
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: please, no space before tabs
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: line over 80 characters
    torvalds#440: FILE: drivers/tty/serial/sunzilog.c:440:
    +		/* The Zilog just gives us an interrupt when DCD/CTS/etc. change.

    WARNING: line over 80 characters
    torvalds#441: FILE: drivers/tty/serial/sunzilog.c:441:
    +		 * But it does not tell us which bit has changed, we have to keep

    WARNING: Missing a blank line after declarations
    torvalds#464: FILE: drivers/tty/serial/sunzilog.c:464:
    +		unsigned char status = readb(&channel->control);
    +		ZSDELAY();

    WARNING: line over 80 characters
    torvalds#468: FILE: drivers/tty/serial/sunzilog.c:468:
    +		 * It can occur because of how we do serial console writes.  It would

    WARNING: line over 80 characters
    torvalds#469: FILE: drivers/tty/serial/sunzilog.c:469:
    +		 * be nice to transmit console writes just like we normally would for

    WARNING: line over 80 characters
    torvalds#470: FILE: drivers/tty/serial/sunzilog.c:470:
    +		 * a TTY line. (ie. buffered and TX interrupt driven).  That is not

    WARNING: line over 80 characters
    torvalds#471: FILE: drivers/tty/serial/sunzilog.c:471:
    +		 * easy because console writes cannot sleep.  One solution might be

    WARNING: line over 80 characters
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    WARNING: plain inline is preferred over __inline__
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    ERROR: trailing whitespace
    torvalds#664: FILE: drivers/tty/serial/sunzilog.c:664:
    +^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#752: FILE: drivers/tty/serial/sunzilog.c:752:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#779: FILE: drivers/tty/serial/sunzilog.c:779:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    WARNING: line over 80 characters
    #999: FILE: drivers/tty/serial/sunzilog.c:999:
    +static int sunzilog_verify_port(struct uart_port *port, struct serial_struct *ser)

    WARNING: Missing a blank line after declarations
    #1142: FILE: drivers/tty/serial/sunzilog.c:1142:
    +		unsigned char val = readb(&channel->control);
    +		if (val & Tx_BUF_EMP) {

    WARNING: Prefer [subsystem eg: netdev]_info([subsystem]dev, ... then dev_info(dev, ... then pr_info(...  to printk(KERN_INFO ...
    #1230: FILE: drivers/tty/serial/sunzilog.c:1230:
    +	printk(KERN_INFO "Console: ttyS%d (SunZilog zs%d)\n",

    WARNING: braces {} are not necessary for single statement blocks
    #1383: FILE: drivers/tty/serial/sunzilog.c:1383:
    +		if (__load_zsregs(channel, up->curregs)) {
    +			up->flags |= SUNZILOG_FLAG_ESCC;
    +		}

    WARNING: quoted string split across lines
    #1493: FILE: drivers/tty/serial/sunzilog.c:1493:
    +		dev_info(&op->dev, "Keyboard at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: quoted string split across lines
    #1497: FILE: drivers/tty/serial/sunzilog.c:1497:
    +		dev_info(&op->dev, "Mouse at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: Missing a blank line after declarations
    #1581: FILE: drivers/tty/serial/sunzilog.c:1581:
    +		struct uart_sunzilog_port *up = sunzilog_irq_chain;
    +		err = request_irq(zilog_irq, sunzilog_interrupt, IRQF_SHARED,

    WARNING: line over 80 characters
    #1590: FILE: drivers/tty/serial/sunzilog.c:1590:
    +			/* printk (KERN_INFO "Enable IRQ for ZILOG Hardware %p\n", up); */

    WARNING: line over 80 characters
    #1627: FILE: drivers/tty/serial/sunzilog.c:1627:
    +			/* printk (KERN_INFO "Disable IRQ for ZILOG Hardware %p\n", up); */

    ERROR: trailing statements should be on next line
    #1248: FILE: drivers/tty/serial/sunzilog.c:1248:
    +	case B150: baud = 150; break;

    ERROR: trailing statements should be on next line
    #1249: FILE: drivers/tty/serial/sunzilog.c:1249:
    +	case B300: baud = 300; break;

    ERROR: trailing statements should be on next line
    #1250: FILE: drivers/tty/serial/sunzilog.c:1250:
    +	case B600: baud = 600; break;

    ERROR: trailing statements should be on next line
    #1251: FILE: drivers/tty/serial/sunzilog.c:1251:
    +	case B1200: baud = 1200; break;

    ERROR: trailing statements should be on next line
    #1252: FILE: drivers/tty/serial/sunzilog.c:1252:
    +	case B2400: baud = 2400; break;

    ERROR: trailing statements should be on next line
    #1253: FILE: drivers/tty/serial/sunzilog.c:1253:
    +	case B4800: baud = 4800; break;

    ERROR: trailing statements should be on next line
    #1254: FILE: drivers/tty/serial/sunzilog.c:1254:
    +	default: case B9600: baud = 9600; break;

    ERROR: trailing statements should be on next line
    #1255: FILE: drivers/tty/serial/sunzilog.c:1255:
    +	case B19200: baud = 19200; break;

    ERROR: trailing statements should be on next line
    #1256: FILE: drivers/tty/serial/sunzilog.c:1256:
    +	case B38400: baud = 38400; break;

Signed-off-by: Enrico Weigelt <info@metux.net>
metux added a commit to metux/linux that referenced this pull request Apr 30, 2019
Fix checkpatch warnings:

    WARNING: Use #include <linux/io.h> instead of <asm/io.h>
    torvalds#38: FILE: drivers/tty/serial/sunzilog.c:38:
    +#include <asm/io.h>

    WARNING: line over 80 characters
    torvalds#109: FILE: drivers/tty/serial/sunzilog.c:109:
    +#define ZILOG_CHANNEL_FROM_PORT(PORT)	((struct zilog_channel __iomem *)((PORT)->membase))

    WARNING: line over 80 characters
    torvalds#116: FILE: drivers/tty/serial/sunzilog.c:116:
    +#define ZS_WANTS_MODEM_STATUS(UP)	((UP)->flags & SUNZILOG_FLAG_MODEM_STATUS)

    WARNING: line over 80 characters
    torvalds#179: FILE: drivers/tty/serial/sunzilog.c:179:
    +static int __load_zsregs(struct zilog_channel __iomem *channel, unsigned char *regs)

    WARNING: Missing a blank line after declarations
    torvalds#188: FILE: drivers/tty/serial/sunzilog.c:188:
    +		unsigned char stat = read_zsreg(channel, R1);
    +		if (stat & ALL_SNT)

    ERROR: trailing whitespace
    torvalds#231: FILE: drivers/tty/serial/sunzilog.c:231:
    +^I$

    WARNING: braces {} are not necessary for any arm of this statement
    torvalds#276: FILE: drivers/tty/serial/sunzilog.c:276:
    +		if (ZS_TX_ACTIVE(up)) {
    [...]
    +		} else {
    [...]

    ERROR: else should follow close brace '}'
    torvalds#378: FILE: drivers/tty/serial/sunzilog.c:378:
    +			}
    +			else if (r1 & PAR_ERR)

    ERROR: code indent should use tabs where possible
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: please, no space before tabs
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: line over 80 characters
    torvalds#440: FILE: drivers/tty/serial/sunzilog.c:440:
    +		/* The Zilog just gives us an interrupt when DCD/CTS/etc. change.

    WARNING: line over 80 characters
    torvalds#441: FILE: drivers/tty/serial/sunzilog.c:441:
    +		 * But it does not tell us which bit has changed, we have to keep

    WARNING: Missing a blank line after declarations
    torvalds#464: FILE: drivers/tty/serial/sunzilog.c:464:
    +		unsigned char status = readb(&channel->control);
    +		ZSDELAY();

    WARNING: line over 80 characters
    torvalds#468: FILE: drivers/tty/serial/sunzilog.c:468:
    +		 * It can occur because of how we do serial console writes.  It would

    WARNING: line over 80 characters
    torvalds#469: FILE: drivers/tty/serial/sunzilog.c:469:
    +		 * be nice to transmit console writes just like we normally would for

    WARNING: line over 80 characters
    torvalds#470: FILE: drivers/tty/serial/sunzilog.c:470:
    +		 * a TTY line. (ie. buffered and TX interrupt driven).  That is not

    WARNING: line over 80 characters
    torvalds#471: FILE: drivers/tty/serial/sunzilog.c:471:
    +		 * easy because console writes cannot sleep.  One solution might be

    WARNING: line over 80 characters
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    WARNING: plain inline is preferred over __inline__
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    ERROR: trailing whitespace
    torvalds#664: FILE: drivers/tty/serial/sunzilog.c:664:
    +^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#752: FILE: drivers/tty/serial/sunzilog.c:752:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#779: FILE: drivers/tty/serial/sunzilog.c:779:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    WARNING: line over 80 characters
    #999: FILE: drivers/tty/serial/sunzilog.c:999:
    +static int sunzilog_verify_port(struct uart_port *port, struct serial_struct *ser)

    WARNING: Missing a blank line after declarations
    #1142: FILE: drivers/tty/serial/sunzilog.c:1142:
    +		unsigned char val = readb(&channel->control);
    +		if (val & Tx_BUF_EMP) {

    WARNING: Prefer [subsystem eg: netdev]_info([subsystem]dev, ... then dev_info(dev, ... then pr_info(...  to printk(KERN_INFO ...
    #1230: FILE: drivers/tty/serial/sunzilog.c:1230:
    +	printk(KERN_INFO "Console: ttyS%d (SunZilog zs%d)\n",

    WARNING: braces {} are not necessary for single statement blocks
    #1383: FILE: drivers/tty/serial/sunzilog.c:1383:
    +		if (__load_zsregs(channel, up->curregs)) {
    +			up->flags |= SUNZILOG_FLAG_ESCC;
    +		}

    WARNING: quoted string split across lines
    #1493: FILE: drivers/tty/serial/sunzilog.c:1493:
    +		dev_info(&op->dev, "Keyboard at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: quoted string split across lines
    #1497: FILE: drivers/tty/serial/sunzilog.c:1497:
    +		dev_info(&op->dev, "Mouse at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: Missing a blank line after declarations
    #1581: FILE: drivers/tty/serial/sunzilog.c:1581:
    +		struct uart_sunzilog_port *up = sunzilog_irq_chain;
    +		err = request_irq(zilog_irq, sunzilog_interrupt, IRQF_SHARED,

    WARNING: line over 80 characters
    #1590: FILE: drivers/tty/serial/sunzilog.c:1590:
    +			/* printk (KERN_INFO "Enable IRQ for ZILOG Hardware %p\n", up); */

    WARNING: line over 80 characters
    #1627: FILE: drivers/tty/serial/sunzilog.c:1627:
    +			/* printk (KERN_INFO "Disable IRQ for ZILOG Hardware %p\n", up); */

    ERROR: trailing statements should be on next line
    #1248: FILE: drivers/tty/serial/sunzilog.c:1248:
    +	case B150: baud = 150; break;

    ERROR: trailing statements should be on next line
    #1249: FILE: drivers/tty/serial/sunzilog.c:1249:
    +	case B300: baud = 300; break;

    ERROR: trailing statements should be on next line
    #1250: FILE: drivers/tty/serial/sunzilog.c:1250:
    +	case B600: baud = 600; break;

    ERROR: trailing statements should be on next line
    #1251: FILE: drivers/tty/serial/sunzilog.c:1251:
    +	case B1200: baud = 1200; break;

    ERROR: trailing statements should be on next line
    #1252: FILE: drivers/tty/serial/sunzilog.c:1252:
    +	case B2400: baud = 2400; break;

    ERROR: trailing statements should be on next line
    #1253: FILE: drivers/tty/serial/sunzilog.c:1253:
    +	case B4800: baud = 4800; break;

    ERROR: trailing statements should be on next line
    #1254: FILE: drivers/tty/serial/sunzilog.c:1254:
    +	default: case B9600: baud = 9600; break;

    ERROR: trailing statements should be on next line
    #1255: FILE: drivers/tty/serial/sunzilog.c:1255:
    +	case B19200: baud = 19200; break;

    ERROR: trailing statements should be on next line
    #1256: FILE: drivers/tty/serial/sunzilog.c:1256:
    +	case B38400: baud = 38400; break;

Signed-off-by: Enrico Weigelt <info@metux.net>
metux added a commit to metux/linux that referenced this pull request Jun 12, 2019
Fix checkpatch warnings:

    WARNING: Use #include <linux/io.h> instead of <asm/io.h>
    torvalds#38: FILE: drivers/tty/serial/sunzilog.c:38:
    +#include <asm/io.h>

    WARNING: line over 80 characters
    torvalds#109: FILE: drivers/tty/serial/sunzilog.c:109:
    +#define ZILOG_CHANNEL_FROM_PORT(PORT)	((struct zilog_channel __iomem *)((PORT)->membase))

    WARNING: line over 80 characters
    torvalds#116: FILE: drivers/tty/serial/sunzilog.c:116:
    +#define ZS_WANTS_MODEM_STATUS(UP)	((UP)->flags & SUNZILOG_FLAG_MODEM_STATUS)

    WARNING: line over 80 characters
    torvalds#179: FILE: drivers/tty/serial/sunzilog.c:179:
    +static int __load_zsregs(struct zilog_channel __iomem *channel, unsigned char *regs)

    WARNING: Missing a blank line after declarations
    torvalds#188: FILE: drivers/tty/serial/sunzilog.c:188:
    +		unsigned char stat = read_zsreg(channel, R1);
    +		if (stat & ALL_SNT)

    ERROR: trailing whitespace
    torvalds#231: FILE: drivers/tty/serial/sunzilog.c:231:
    +^I$

    WARNING: braces {} are not necessary for any arm of this statement
    torvalds#276: FILE: drivers/tty/serial/sunzilog.c:276:
    +		if (ZS_TX_ACTIVE(up)) {
    [...]
    +		} else {
    [...]

    ERROR: else should follow close brace '}'
    torvalds#378: FILE: drivers/tty/serial/sunzilog.c:378:
    +			}
    +			else if (r1 & PAR_ERR)

    ERROR: code indent should use tabs where possible
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: please, no space before tabs
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: line over 80 characters
    torvalds#440: FILE: drivers/tty/serial/sunzilog.c:440:
    +		/* The Zilog just gives us an interrupt when DCD/CTS/etc. change.

    WARNING: line over 80 characters
    torvalds#441: FILE: drivers/tty/serial/sunzilog.c:441:
    +		 * But it does not tell us which bit has changed, we have to keep

    WARNING: Missing a blank line after declarations
    torvalds#464: FILE: drivers/tty/serial/sunzilog.c:464:
    +		unsigned char status = readb(&channel->control);
    +		ZSDELAY();

    WARNING: line over 80 characters
    torvalds#468: FILE: drivers/tty/serial/sunzilog.c:468:
    +		 * It can occur because of how we do serial console writes.  It would

    WARNING: line over 80 characters
    torvalds#469: FILE: drivers/tty/serial/sunzilog.c:469:
    +		 * be nice to transmit console writes just like we normally would for

    WARNING: line over 80 characters
    torvalds#470: FILE: drivers/tty/serial/sunzilog.c:470:
    +		 * a TTY line. (ie. buffered and TX interrupt driven).  That is not

    WARNING: line over 80 characters
    torvalds#471: FILE: drivers/tty/serial/sunzilog.c:471:
    +		 * easy because console writes cannot sleep.  One solution might be

    WARNING: line over 80 characters
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    WARNING: plain inline is preferred over __inline__
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    ERROR: trailing whitespace
    torvalds#664: FILE: drivers/tty/serial/sunzilog.c:664:
    +^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#752: FILE: drivers/tty/serial/sunzilog.c:752:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#779: FILE: drivers/tty/serial/sunzilog.c:779:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    WARNING: line over 80 characters
    #999: FILE: drivers/tty/serial/sunzilog.c:999:
    +static int sunzilog_verify_port(struct uart_port *port, struct serial_struct *ser)

    WARNING: Missing a blank line after declarations
    #1142: FILE: drivers/tty/serial/sunzilog.c:1142:
    +		unsigned char val = readb(&channel->control);
    +		if (val & Tx_BUF_EMP) {

    WARNING: Prefer [subsystem eg: netdev]_info([subsystem]dev, ... then dev_info(dev, ... then pr_info(...  to printk(KERN_INFO ...
    #1230: FILE: drivers/tty/serial/sunzilog.c:1230:
    +	printk(KERN_INFO "Console: ttyS%d (SunZilog zs%d)\n",

    WARNING: braces {} are not necessary for single statement blocks
    #1383: FILE: drivers/tty/serial/sunzilog.c:1383:
    +		if (__load_zsregs(channel, up->curregs)) {
    +			up->flags |= SUNZILOG_FLAG_ESCC;
    +		}

    WARNING: quoted string split across lines
    #1493: FILE: drivers/tty/serial/sunzilog.c:1493:
    +		dev_info(&op->dev, "Keyboard at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: quoted string split across lines
    #1497: FILE: drivers/tty/serial/sunzilog.c:1497:
    +		dev_info(&op->dev, "Mouse at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: Missing a blank line after declarations
    #1581: FILE: drivers/tty/serial/sunzilog.c:1581:
    +		struct uart_sunzilog_port *up = sunzilog_irq_chain;
    +		err = request_irq(zilog_irq, sunzilog_interrupt, IRQF_SHARED,

    WARNING: line over 80 characters
    #1590: FILE: drivers/tty/serial/sunzilog.c:1590:
    +			/* printk (KERN_INFO "Enable IRQ for ZILOG Hardware %p\n", up); */

    WARNING: line over 80 characters
    #1627: FILE: drivers/tty/serial/sunzilog.c:1627:
    +			/* printk (KERN_INFO "Disable IRQ for ZILOG Hardware %p\n", up); */

    ERROR: trailing statements should be on next line
    #1248: FILE: drivers/tty/serial/sunzilog.c:1248:
    +	case B150: baud = 150; break;

    ERROR: trailing statements should be on next line
    #1249: FILE: drivers/tty/serial/sunzilog.c:1249:
    +	case B300: baud = 300; break;

    ERROR: trailing statements should be on next line
    #1250: FILE: drivers/tty/serial/sunzilog.c:1250:
    +	case B600: baud = 600; break;

    ERROR: trailing statements should be on next line
    #1251: FILE: drivers/tty/serial/sunzilog.c:1251:
    +	case B1200: baud = 1200; break;

    ERROR: trailing statements should be on next line
    #1252: FILE: drivers/tty/serial/sunzilog.c:1252:
    +	case B2400: baud = 2400; break;

    ERROR: trailing statements should be on next line
    #1253: FILE: drivers/tty/serial/sunzilog.c:1253:
    +	case B4800: baud = 4800; break;

    ERROR: trailing statements should be on next line
    #1254: FILE: drivers/tty/serial/sunzilog.c:1254:
    +	default: case B9600: baud = 9600; break;

    ERROR: trailing statements should be on next line
    #1255: FILE: drivers/tty/serial/sunzilog.c:1255:
    +	case B19200: baud = 19200; break;

    ERROR: trailing statements should be on next line
    #1256: FILE: drivers/tty/serial/sunzilog.c:1256:
    +	case B38400: baud = 38400; break;

Signed-off-by: Enrico Weigelt <info@metux.net>
metux added a commit to metux/linux that referenced this pull request Jun 27, 2019
Fix checkpatch warnings:

    WARNING: Use #include <linux/io.h> instead of <asm/io.h>
    torvalds#38: FILE: drivers/tty/serial/sunzilog.c:38:
    +#include <asm/io.h>

    WARNING: line over 80 characters
    torvalds#109: FILE: drivers/tty/serial/sunzilog.c:109:
    +#define ZILOG_CHANNEL_FROM_PORT(PORT)	((struct zilog_channel __iomem *)((PORT)->membase))

    WARNING: line over 80 characters
    torvalds#116: FILE: drivers/tty/serial/sunzilog.c:116:
    +#define ZS_WANTS_MODEM_STATUS(UP)	((UP)->flags & SUNZILOG_FLAG_MODEM_STATUS)

    WARNING: line over 80 characters
    torvalds#179: FILE: drivers/tty/serial/sunzilog.c:179:
    +static int __load_zsregs(struct zilog_channel __iomem *channel, unsigned char *regs)

    WARNING: Missing a blank line after declarations
    torvalds#188: FILE: drivers/tty/serial/sunzilog.c:188:
    +		unsigned char stat = read_zsreg(channel, R1);
    +		if (stat & ALL_SNT)

    ERROR: trailing whitespace
    torvalds#231: FILE: drivers/tty/serial/sunzilog.c:231:
    +^I$

    WARNING: braces {} are not necessary for any arm of this statement
    torvalds#276: FILE: drivers/tty/serial/sunzilog.c:276:
    +		if (ZS_TX_ACTIVE(up)) {
    [...]
    +		} else {
    [...]

    ERROR: else should follow close brace '}'
    torvalds#378: FILE: drivers/tty/serial/sunzilog.c:378:
    +			}
    +			else if (r1 & PAR_ERR)

    ERROR: code indent should use tabs where possible
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: please, no space before tabs
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: line over 80 characters
    torvalds#440: FILE: drivers/tty/serial/sunzilog.c:440:
    +		/* The Zilog just gives us an interrupt when DCD/CTS/etc. change.

    WARNING: line over 80 characters
    torvalds#441: FILE: drivers/tty/serial/sunzilog.c:441:
    +		 * But it does not tell us which bit has changed, we have to keep

    WARNING: Missing a blank line after declarations
    torvalds#464: FILE: drivers/tty/serial/sunzilog.c:464:
    +		unsigned char status = readb(&channel->control);
    +		ZSDELAY();

    WARNING: line over 80 characters
    torvalds#468: FILE: drivers/tty/serial/sunzilog.c:468:
    +		 * It can occur because of how we do serial console writes.  It would

    WARNING: line over 80 characters
    torvalds#469: FILE: drivers/tty/serial/sunzilog.c:469:
    +		 * be nice to transmit console writes just like we normally would for

    WARNING: line over 80 characters
    torvalds#470: FILE: drivers/tty/serial/sunzilog.c:470:
    +		 * a TTY line. (ie. buffered and TX interrupt driven).  That is not

    WARNING: line over 80 characters
    torvalds#471: FILE: drivers/tty/serial/sunzilog.c:471:
    +		 * easy because console writes cannot sleep.  One solution might be

    WARNING: line over 80 characters
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    WARNING: plain inline is preferred over __inline__
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    ERROR: trailing whitespace
    torvalds#664: FILE: drivers/tty/serial/sunzilog.c:664:
    +^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#752: FILE: drivers/tty/serial/sunzilog.c:752:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#779: FILE: drivers/tty/serial/sunzilog.c:779:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    WARNING: line over 80 characters
    #999: FILE: drivers/tty/serial/sunzilog.c:999:
    +static int sunzilog_verify_port(struct uart_port *port, struct serial_struct *ser)

    WARNING: Missing a blank line after declarations
    #1142: FILE: drivers/tty/serial/sunzilog.c:1142:
    +		unsigned char val = readb(&channel->control);
    +		if (val & Tx_BUF_EMP) {

    WARNING: Prefer [subsystem eg: netdev]_info([subsystem]dev, ... then dev_info(dev, ... then pr_info(...  to printk(KERN_INFO ...
    #1230: FILE: drivers/tty/serial/sunzilog.c:1230:
    +	printk(KERN_INFO "Console: ttyS%d (SunZilog zs%d)\n",

    WARNING: braces {} are not necessary for single statement blocks
    #1383: FILE: drivers/tty/serial/sunzilog.c:1383:
    +		if (__load_zsregs(channel, up->curregs)) {
    +			up->flags |= SUNZILOG_FLAG_ESCC;
    +		}

    WARNING: quoted string split across lines
    #1493: FILE: drivers/tty/serial/sunzilog.c:1493:
    +		dev_info(&op->dev, "Keyboard at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: quoted string split across lines
    #1497: FILE: drivers/tty/serial/sunzilog.c:1497:
    +		dev_info(&op->dev, "Mouse at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: Missing a blank line after declarations
    #1581: FILE: drivers/tty/serial/sunzilog.c:1581:
    +		struct uart_sunzilog_port *up = sunzilog_irq_chain;
    +		err = request_irq(zilog_irq, sunzilog_interrupt, IRQF_SHARED,

    WARNING: line over 80 characters
    #1590: FILE: drivers/tty/serial/sunzilog.c:1590:
    +			/* printk (KERN_INFO "Enable IRQ for ZILOG Hardware %p\n", up); */

    WARNING: line over 80 characters
    #1627: FILE: drivers/tty/serial/sunzilog.c:1627:
    +			/* printk (KERN_INFO "Disable IRQ for ZILOG Hardware %p\n", up); */

    ERROR: trailing statements should be on next line
    #1248: FILE: drivers/tty/serial/sunzilog.c:1248:
    +	case B150: baud = 150; break;

    ERROR: trailing statements should be on next line
    #1249: FILE: drivers/tty/serial/sunzilog.c:1249:
    +	case B300: baud = 300; break;

    ERROR: trailing statements should be on next line
    #1250: FILE: drivers/tty/serial/sunzilog.c:1250:
    +	case B600: baud = 600; break;

    ERROR: trailing statements should be on next line
    #1251: FILE: drivers/tty/serial/sunzilog.c:1251:
    +	case B1200: baud = 1200; break;

    ERROR: trailing statements should be on next line
    #1252: FILE: drivers/tty/serial/sunzilog.c:1252:
    +	case B2400: baud = 2400; break;

    ERROR: trailing statements should be on next line
    #1253: FILE: drivers/tty/serial/sunzilog.c:1253:
    +	case B4800: baud = 4800; break;

    ERROR: trailing statements should be on next line
    #1254: FILE: drivers/tty/serial/sunzilog.c:1254:
    +	default: case B9600: baud = 9600; break;

    ERROR: trailing statements should be on next line
    #1255: FILE: drivers/tty/serial/sunzilog.c:1255:
    +	case B19200: baud = 19200; break;

    ERROR: trailing statements should be on next line
    #1256: FILE: drivers/tty/serial/sunzilog.c:1256:
    +	case B38400: baud = 38400; break;

Signed-off-by: Enrico Weigelt <info@metux.net>
metux added a commit to metux/linux that referenced this pull request Jul 10, 2019
Fix checkpatch warnings:

    WARNING: Use #include <linux/io.h> instead of <asm/io.h>
    torvalds#38: FILE: drivers/tty/serial/sunzilog.c:38:
    +#include <asm/io.h>

    WARNING: line over 80 characters
    torvalds#109: FILE: drivers/tty/serial/sunzilog.c:109:
    +#define ZILOG_CHANNEL_FROM_PORT(PORT)	((struct zilog_channel __iomem *)((PORT)->membase))

    WARNING: line over 80 characters
    torvalds#116: FILE: drivers/tty/serial/sunzilog.c:116:
    +#define ZS_WANTS_MODEM_STATUS(UP)	((UP)->flags & SUNZILOG_FLAG_MODEM_STATUS)

    WARNING: line over 80 characters
    torvalds#179: FILE: drivers/tty/serial/sunzilog.c:179:
    +static int __load_zsregs(struct zilog_channel __iomem *channel, unsigned char *regs)

    WARNING: Missing a blank line after declarations
    torvalds#188: FILE: drivers/tty/serial/sunzilog.c:188:
    +		unsigned char stat = read_zsreg(channel, R1);
    +		if (stat & ALL_SNT)

    ERROR: trailing whitespace
    torvalds#231: FILE: drivers/tty/serial/sunzilog.c:231:
    +^I$

    WARNING: braces {} are not necessary for any arm of this statement
    torvalds#276: FILE: drivers/tty/serial/sunzilog.c:276:
    +		if (ZS_TX_ACTIVE(up)) {
    [...]
    +		} else {
    [...]

    ERROR: else should follow close brace '}'
    torvalds#378: FILE: drivers/tty/serial/sunzilog.c:378:
    +			}
    +			else if (r1 & PAR_ERR)

    ERROR: code indent should use tabs where possible
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: please, no space before tabs
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: line over 80 characters
    torvalds#440: FILE: drivers/tty/serial/sunzilog.c:440:
    +		/* The Zilog just gives us an interrupt when DCD/CTS/etc. change.

    WARNING: line over 80 characters
    torvalds#441: FILE: drivers/tty/serial/sunzilog.c:441:
    +		 * But it does not tell us which bit has changed, we have to keep

    WARNING: Missing a blank line after declarations
    torvalds#464: FILE: drivers/tty/serial/sunzilog.c:464:
    +		unsigned char status = readb(&channel->control);
    +		ZSDELAY();

    WARNING: line over 80 characters
    torvalds#468: FILE: drivers/tty/serial/sunzilog.c:468:
    +		 * It can occur because of how we do serial console writes.  It would

    WARNING: line over 80 characters
    torvalds#469: FILE: drivers/tty/serial/sunzilog.c:469:
    +		 * be nice to transmit console writes just like we normally would for

    WARNING: line over 80 characters
    torvalds#470: FILE: drivers/tty/serial/sunzilog.c:470:
    +		 * a TTY line. (ie. buffered and TX interrupt driven).  That is not

    WARNING: line over 80 characters
    torvalds#471: FILE: drivers/tty/serial/sunzilog.c:471:
    +		 * easy because console writes cannot sleep.  One solution might be

    WARNING: line over 80 characters
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    WARNING: plain inline is preferred over __inline__
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    ERROR: trailing whitespace
    torvalds#664: FILE: drivers/tty/serial/sunzilog.c:664:
    +^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#752: FILE: drivers/tty/serial/sunzilog.c:752:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#779: FILE: drivers/tty/serial/sunzilog.c:779:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    WARNING: line over 80 characters
    #999: FILE: drivers/tty/serial/sunzilog.c:999:
    +static int sunzilog_verify_port(struct uart_port *port, struct serial_struct *ser)

    WARNING: Missing a blank line after declarations
    #1142: FILE: drivers/tty/serial/sunzilog.c:1142:
    +		unsigned char val = readb(&channel->control);
    +		if (val & Tx_BUF_EMP) {

    WARNING: Prefer [subsystem eg: netdev]_info([subsystem]dev, ... then dev_info(dev, ... then pr_info(...  to printk(KERN_INFO ...
    #1230: FILE: drivers/tty/serial/sunzilog.c:1230:
    +	printk(KERN_INFO "Console: ttyS%d (SunZilog zs%d)\n",

    WARNING: braces {} are not necessary for single statement blocks
    #1383: FILE: drivers/tty/serial/sunzilog.c:1383:
    +		if (__load_zsregs(channel, up->curregs)) {
    +			up->flags |= SUNZILOG_FLAG_ESCC;
    +		}

    WARNING: quoted string split across lines
    #1493: FILE: drivers/tty/serial/sunzilog.c:1493:
    +		dev_info(&op->dev, "Keyboard at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: quoted string split across lines
    #1497: FILE: drivers/tty/serial/sunzilog.c:1497:
    +		dev_info(&op->dev, "Mouse at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: Missing a blank line after declarations
    #1581: FILE: drivers/tty/serial/sunzilog.c:1581:
    +		struct uart_sunzilog_port *up = sunzilog_irq_chain;
    +		err = request_irq(zilog_irq, sunzilog_interrupt, IRQF_SHARED,

    WARNING: line over 80 characters
    #1590: FILE: drivers/tty/serial/sunzilog.c:1590:
    +			/* printk (KERN_INFO "Enable IRQ for ZILOG Hardware %p\n", up); */

    WARNING: line over 80 characters
    #1627: FILE: drivers/tty/serial/sunzilog.c:1627:
    +			/* printk (KERN_INFO "Disable IRQ for ZILOG Hardware %p\n", up); */

    ERROR: trailing statements should be on next line
    #1248: FILE: drivers/tty/serial/sunzilog.c:1248:
    +	case B150: baud = 150; break;

    ERROR: trailing statements should be on next line
    #1249: FILE: drivers/tty/serial/sunzilog.c:1249:
    +	case B300: baud = 300; break;

    ERROR: trailing statements should be on next line
    #1250: FILE: drivers/tty/serial/sunzilog.c:1250:
    +	case B600: baud = 600; break;

    ERROR: trailing statements should be on next line
    #1251: FILE: drivers/tty/serial/sunzilog.c:1251:
    +	case B1200: baud = 1200; break;

    ERROR: trailing statements should be on next line
    #1252: FILE: drivers/tty/serial/sunzilog.c:1252:
    +	case B2400: baud = 2400; break;

    ERROR: trailing statements should be on next line
    #1253: FILE: drivers/tty/serial/sunzilog.c:1253:
    +	case B4800: baud = 4800; break;

    ERROR: trailing statements should be on next line
    #1254: FILE: drivers/tty/serial/sunzilog.c:1254:
    +	default: case B9600: baud = 9600; break;

    ERROR: trailing statements should be on next line
    #1255: FILE: drivers/tty/serial/sunzilog.c:1255:
    +	case B19200: baud = 19200; break;

    ERROR: trailing statements should be on next line
    #1256: FILE: drivers/tty/serial/sunzilog.c:1256:
    +	case B38400: baud = 38400; break;

Signed-off-by: Enrico Weigelt <info@metux.net>
ddiss pushed a commit to ddiss/linux that referenced this pull request Sep 5, 2019
metux added a commit to metux/linux that referenced this pull request Nov 21, 2019
Fix checkpatch warnings:

    WARNING: Use #include <linux/io.h> instead of <asm/io.h>
    torvalds#38: FILE: drivers/tty/serial/sunzilog.c:38:
    +#include <asm/io.h>

    WARNING: line over 80 characters
    torvalds#109: FILE: drivers/tty/serial/sunzilog.c:109:
    +#define ZILOG_CHANNEL_FROM_PORT(PORT)	((struct zilog_channel __iomem *)((PORT)->membase))

    WARNING: line over 80 characters
    torvalds#116: FILE: drivers/tty/serial/sunzilog.c:116:
    +#define ZS_WANTS_MODEM_STATUS(UP)	((UP)->flags & SUNZILOG_FLAG_MODEM_STATUS)

    WARNING: line over 80 characters
    torvalds#179: FILE: drivers/tty/serial/sunzilog.c:179:
    +static int __load_zsregs(struct zilog_channel __iomem *channel, unsigned char *regs)

    WARNING: Missing a blank line after declarations
    torvalds#188: FILE: drivers/tty/serial/sunzilog.c:188:
    +		unsigned char stat = read_zsreg(channel, R1);
    +		if (stat & ALL_SNT)

    ERROR: trailing whitespace
    torvalds#231: FILE: drivers/tty/serial/sunzilog.c:231:
    +^I$

    WARNING: braces {} are not necessary for any arm of this statement
    torvalds#276: FILE: drivers/tty/serial/sunzilog.c:276:
    +		if (ZS_TX_ACTIVE(up)) {
    [...]
    +		} else {
    [...]

    ERROR: else should follow close brace '}'
    torvalds#378: FILE: drivers/tty/serial/sunzilog.c:378:
    +			}
    +			else if (r1 & PAR_ERR)

    ERROR: code indent should use tabs where possible
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: please, no space before tabs
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: line over 80 characters
    torvalds#440: FILE: drivers/tty/serial/sunzilog.c:440:
    +		/* The Zilog just gives us an interrupt when DCD/CTS/etc. change.

    WARNING: line over 80 characters
    torvalds#441: FILE: drivers/tty/serial/sunzilog.c:441:
    +		 * But it does not tell us which bit has changed, we have to keep

    WARNING: Missing a blank line after declarations
    torvalds#464: FILE: drivers/tty/serial/sunzilog.c:464:
    +		unsigned char status = readb(&channel->control);
    +		ZSDELAY();

    WARNING: line over 80 characters
    torvalds#468: FILE: drivers/tty/serial/sunzilog.c:468:
    +		 * It can occur because of how we do serial console writes.  It would

    WARNING: line over 80 characters
    torvalds#469: FILE: drivers/tty/serial/sunzilog.c:469:
    +		 * be nice to transmit console writes just like we normally would for

    WARNING: line over 80 characters
    torvalds#470: FILE: drivers/tty/serial/sunzilog.c:470:
    +		 * a TTY line. (ie. buffered and TX interrupt driven).  That is not

    WARNING: line over 80 characters
    torvalds#471: FILE: drivers/tty/serial/sunzilog.c:471:
    +		 * easy because console writes cannot sleep.  One solution might be

    WARNING: line over 80 characters
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    WARNING: plain inline is preferred over __inline__
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    ERROR: trailing whitespace
    torvalds#664: FILE: drivers/tty/serial/sunzilog.c:664:
    +^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#752: FILE: drivers/tty/serial/sunzilog.c:752:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#779: FILE: drivers/tty/serial/sunzilog.c:779:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    WARNING: line over 80 characters
    #999: FILE: drivers/tty/serial/sunzilog.c:999:
    +static int sunzilog_verify_port(struct uart_port *port, struct serial_struct *ser)

    WARNING: Missing a blank line after declarations
    #1142: FILE: drivers/tty/serial/sunzilog.c:1142:
    +		unsigned char val = readb(&channel->control);
    +		if (val & Tx_BUF_EMP) {

    WARNING: Prefer [subsystem eg: netdev]_info([subsystem]dev, ... then dev_info(dev, ... then pr_info(...  to printk(KERN_INFO ...
    #1230: FILE: drivers/tty/serial/sunzilog.c:1230:
    +	printk(KERN_INFO "Console: ttyS%d (SunZilog zs%d)\n",

    WARNING: braces {} are not necessary for single statement blocks
    #1383: FILE: drivers/tty/serial/sunzilog.c:1383:
    +		if (__load_zsregs(channel, up->curregs)) {
    +			up->flags |= SUNZILOG_FLAG_ESCC;
    +		}

    WARNING: quoted string split across lines
    #1493: FILE: drivers/tty/serial/sunzilog.c:1493:
    +		dev_info(&op->dev, "Keyboard at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: quoted string split across lines
    #1497: FILE: drivers/tty/serial/sunzilog.c:1497:
    +		dev_info(&op->dev, "Mouse at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: Missing a blank line after declarations
    #1581: FILE: drivers/tty/serial/sunzilog.c:1581:
    +		struct uart_sunzilog_port *up = sunzilog_irq_chain;
    +		err = request_irq(zilog_irq, sunzilog_interrupt, IRQF_SHARED,

    WARNING: line over 80 characters
    #1590: FILE: drivers/tty/serial/sunzilog.c:1590:
    +			/* printk (KERN_INFO "Enable IRQ for ZILOG Hardware %p\n", up); */

    WARNING: line over 80 characters
    #1627: FILE: drivers/tty/serial/sunzilog.c:1627:
    +			/* printk (KERN_INFO "Disable IRQ for ZILOG Hardware %p\n", up); */

    ERROR: trailing statements should be on next line
    #1248: FILE: drivers/tty/serial/sunzilog.c:1248:
    +	case B150: baud = 150; break;

    ERROR: trailing statements should be on next line
    #1249: FILE: drivers/tty/serial/sunzilog.c:1249:
    +	case B300: baud = 300; break;

    ERROR: trailing statements should be on next line
    #1250: FILE: drivers/tty/serial/sunzilog.c:1250:
    +	case B600: baud = 600; break;

    ERROR: trailing statements should be on next line
    #1251: FILE: drivers/tty/serial/sunzilog.c:1251:
    +	case B1200: baud = 1200; break;

    ERROR: trailing statements should be on next line
    #1252: FILE: drivers/tty/serial/sunzilog.c:1252:
    +	case B2400: baud = 2400; break;

    ERROR: trailing statements should be on next line
    #1253: FILE: drivers/tty/serial/sunzilog.c:1253:
    +	case B4800: baud = 4800; break;

    ERROR: trailing statements should be on next line
    #1254: FILE: drivers/tty/serial/sunzilog.c:1254:
    +	default: case B9600: baud = 9600; break;

    ERROR: trailing statements should be on next line
    #1255: FILE: drivers/tty/serial/sunzilog.c:1255:
    +	case B19200: baud = 19200; break;

    ERROR: trailing statements should be on next line
    #1256: FILE: drivers/tty/serial/sunzilog.c:1256:
    +	case B38400: baud = 38400; break;

Signed-off-by: Enrico Weigelt <info@metux.net>
metux added a commit to metux/linux that referenced this pull request Jan 10, 2020
Fix checkpatch warnings:

    WARNING: Use #include <linux/io.h> instead of <asm/io.h>
    torvalds#38: FILE: drivers/tty/serial/sunzilog.c:38:
    +#include <asm/io.h>

    WARNING: line over 80 characters
    torvalds#109: FILE: drivers/tty/serial/sunzilog.c:109:
    +#define ZILOG_CHANNEL_FROM_PORT(PORT)	((struct zilog_channel __iomem *)((PORT)->membase))

    WARNING: line over 80 characters
    torvalds#116: FILE: drivers/tty/serial/sunzilog.c:116:
    +#define ZS_WANTS_MODEM_STATUS(UP)	((UP)->flags & SUNZILOG_FLAG_MODEM_STATUS)

    WARNING: line over 80 characters
    torvalds#179: FILE: drivers/tty/serial/sunzilog.c:179:
    +static int __load_zsregs(struct zilog_channel __iomem *channel, unsigned char *regs)

    WARNING: Missing a blank line after declarations
    torvalds#188: FILE: drivers/tty/serial/sunzilog.c:188:
    +		unsigned char stat = read_zsreg(channel, R1);
    +		if (stat & ALL_SNT)

    ERROR: trailing whitespace
    torvalds#231: FILE: drivers/tty/serial/sunzilog.c:231:
    +^I$

    WARNING: braces {} are not necessary for any arm of this statement
    torvalds#276: FILE: drivers/tty/serial/sunzilog.c:276:
    +		if (ZS_TX_ACTIVE(up)) {
    [...]
    +		} else {
    [...]

    ERROR: else should follow close brace '}'
    torvalds#378: FILE: drivers/tty/serial/sunzilog.c:378:
    +			}
    +			else if (r1 & PAR_ERR)

    ERROR: code indent should use tabs where possible
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: please, no space before tabs
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: line over 80 characters
    torvalds#440: FILE: drivers/tty/serial/sunzilog.c:440:
    +		/* The Zilog just gives us an interrupt when DCD/CTS/etc. change.

    WARNING: line over 80 characters
    torvalds#441: FILE: drivers/tty/serial/sunzilog.c:441:
    +		 * But it does not tell us which bit has changed, we have to keep

    WARNING: Missing a blank line after declarations
    torvalds#464: FILE: drivers/tty/serial/sunzilog.c:464:
    +		unsigned char status = readb(&channel->control);
    +		ZSDELAY();

    WARNING: line over 80 characters
    torvalds#468: FILE: drivers/tty/serial/sunzilog.c:468:
    +		 * It can occur because of how we do serial console writes.  It would

    WARNING: line over 80 characters
    torvalds#469: FILE: drivers/tty/serial/sunzilog.c:469:
    +		 * be nice to transmit console writes just like we normally would for

    WARNING: line over 80 characters
    torvalds#470: FILE: drivers/tty/serial/sunzilog.c:470:
    +		 * a TTY line. (ie. buffered and TX interrupt driven).  That is not

    WARNING: line over 80 characters
    torvalds#471: FILE: drivers/tty/serial/sunzilog.c:471:
    +		 * easy because console writes cannot sleep.  One solution might be

    WARNING: line over 80 characters
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    WARNING: plain inline is preferred over __inline__
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    ERROR: trailing whitespace
    torvalds#664: FILE: drivers/tty/serial/sunzilog.c:664:
    +^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#752: FILE: drivers/tty/serial/sunzilog.c:752:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#779: FILE: drivers/tty/serial/sunzilog.c:779:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    WARNING: line over 80 characters
    #999: FILE: drivers/tty/serial/sunzilog.c:999:
    +static int sunzilog_verify_port(struct uart_port *port, struct serial_struct *ser)

    WARNING: Missing a blank line after declarations
    #1142: FILE: drivers/tty/serial/sunzilog.c:1142:
    +		unsigned char val = readb(&channel->control);
    +		if (val & Tx_BUF_EMP) {

    WARNING: Prefer [subsystem eg: netdev]_info([subsystem]dev, ... then dev_info(dev, ... then pr_info(...  to printk(KERN_INFO ...
    #1230: FILE: drivers/tty/serial/sunzilog.c:1230:
    +	printk(KERN_INFO "Console: ttyS%d (SunZilog zs%d)\n",

    WARNING: braces {} are not necessary for single statement blocks
    #1383: FILE: drivers/tty/serial/sunzilog.c:1383:
    +		if (__load_zsregs(channel, up->curregs)) {
    +			up->flags |= SUNZILOG_FLAG_ESCC;
    +		}

    WARNING: quoted string split across lines
    #1493: FILE: drivers/tty/serial/sunzilog.c:1493:
    +		dev_info(&op->dev, "Keyboard at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: quoted string split across lines
    #1497: FILE: drivers/tty/serial/sunzilog.c:1497:
    +		dev_info(&op->dev, "Mouse at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: Missing a blank line after declarations
    #1581: FILE: drivers/tty/serial/sunzilog.c:1581:
    +		struct uart_sunzilog_port *up = sunzilog_irq_chain;
    +		err = request_irq(zilog_irq, sunzilog_interrupt, IRQF_SHARED,

    WARNING: line over 80 characters
    #1590: FILE: drivers/tty/serial/sunzilog.c:1590:
    +			/* printk (KERN_INFO "Enable IRQ for ZILOG Hardware %p\n", up); */

    WARNING: line over 80 characters
    #1627: FILE: drivers/tty/serial/sunzilog.c:1627:
    +			/* printk (KERN_INFO "Disable IRQ for ZILOG Hardware %p\n", up); */

    ERROR: trailing statements should be on next line
    #1248: FILE: drivers/tty/serial/sunzilog.c:1248:
    +	case B150: baud = 150; break;

    ERROR: trailing statements should be on next line
    #1249: FILE: drivers/tty/serial/sunzilog.c:1249:
    +	case B300: baud = 300; break;

    ERROR: trailing statements should be on next line
    #1250: FILE: drivers/tty/serial/sunzilog.c:1250:
    +	case B600: baud = 600; break;

    ERROR: trailing statements should be on next line
    #1251: FILE: drivers/tty/serial/sunzilog.c:1251:
    +	case B1200: baud = 1200; break;

    ERROR: trailing statements should be on next line
    #1252: FILE: drivers/tty/serial/sunzilog.c:1252:
    +	case B2400: baud = 2400; break;

    ERROR: trailing statements should be on next line
    #1253: FILE: drivers/tty/serial/sunzilog.c:1253:
    +	case B4800: baud = 4800; break;

    ERROR: trailing statements should be on next line
    #1254: FILE: drivers/tty/serial/sunzilog.c:1254:
    +	default: case B9600: baud = 9600; break;

    ERROR: trailing statements should be on next line
    #1255: FILE: drivers/tty/serial/sunzilog.c:1255:
    +	case B19200: baud = 19200; break;

    ERROR: trailing statements should be on next line
    #1256: FILE: drivers/tty/serial/sunzilog.c:1256:
    +	case B38400: baud = 38400; break;

Signed-off-by: Enrico Weigelt <info@metux.net>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Mar 31, 2020
Fix an oops in dsa_port_phylink_mac_change() caused by a combination
of a20f997 ("net: dsa: Don't instantiate phylink for CPU/DSA
ports unless needed") and the net-dsa-improve-serdes-integration
series of patches 65b7a2c ("Merge branch
'net-dsa-improve-serdes-integration'").

Unable to handle kernel NULL pointer dereference at virtual address 00000124
pgd = c0004000
[00000124] *pgd=00000000
Internal error: Oops: 805 [#1] SMP ARM
Modules linked in: tag_edsa spi_nor mtd xhci_plat_hcd mv88e6xxx(+) xhci_hcd armada_thermal marvell_cesa dsa_core ehci_orion libdes phy_armada38x_comphy at24 mcp3021 sfp evbug spi_orion sff mdio_i2c
CPU: 1 PID: 214 Comm: irq/55-mv88e6xx Not tainted 5.6.0+ torvalds#470
Hardware name: Marvell Armada 380/385 (Device Tree)
PC is at phylink_mac_change+0x10/0x88
LR is at mv88e6352_serdes_irq_status+0x74/0x94 [mv88e6xxx]

Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
alaahl pushed a commit to alaahl/linux that referenced this pull request Mar 31, 2020
Fix an oops in dsa_port_phylink_mac_change() caused by a combination
of a20f997 ("net: dsa: Don't instantiate phylink for CPU/DSA
ports unless needed") and the net-dsa-improve-serdes-integration
series of patches 65b7a2c ("Merge branch
'net-dsa-improve-serdes-integration'").

Unable to handle kernel NULL pointer dereference at virtual address 00000124
pgd = c0004000
[00000124] *pgd=00000000
Internal error: Oops: 805 [#1] SMP ARM
Modules linked in: tag_edsa spi_nor mtd xhci_plat_hcd mv88e6xxx(+) xhci_hcd armada_thermal marvell_cesa dsa_core ehci_orion libdes phy_armada38x_comphy at24 mcp3021 sfp evbug spi_orion sff mdio_i2c
CPU: 1 PID: 214 Comm: irq/55-mv88e6xx Not tainted 5.6.0+ torvalds#470
Hardware name: Marvell Armada 380/385 (Device Tree)
PC is at phylink_mac_change+0x10/0x88
LR is at mv88e6352_serdes_irq_status+0x74/0x94 [mv88e6xxx]

Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
metux added a commit to metux/linux that referenced this pull request Feb 4, 2021
Fix checkpatch warnings:

    WARNING: Use #include <linux/io.h> instead of <asm/io.h>
    torvalds#38: FILE: drivers/tty/serial/sunzilog.c:38:
    +#include <asm/io.h>

    WARNING: line over 80 characters
    torvalds#109: FILE: drivers/tty/serial/sunzilog.c:109:
    +#define ZILOG_CHANNEL_FROM_PORT(PORT)	((struct zilog_channel __iomem *)((PORT)->membase))

    WARNING: line over 80 characters
    torvalds#116: FILE: drivers/tty/serial/sunzilog.c:116:
    +#define ZS_WANTS_MODEM_STATUS(UP)	((UP)->flags & SUNZILOG_FLAG_MODEM_STATUS)

    WARNING: line over 80 characters
    torvalds#179: FILE: drivers/tty/serial/sunzilog.c:179:
    +static int __load_zsregs(struct zilog_channel __iomem *channel, unsigned char *regs)

    WARNING: Missing a blank line after declarations
    torvalds#188: FILE: drivers/tty/serial/sunzilog.c:188:
    +		unsigned char stat = read_zsreg(channel, R1);
    +		if (stat & ALL_SNT)

    ERROR: trailing whitespace
    torvalds#231: FILE: drivers/tty/serial/sunzilog.c:231:
    +^I$

    WARNING: braces {} are not necessary for any arm of this statement
    torvalds#276: FILE: drivers/tty/serial/sunzilog.c:276:
    +		if (ZS_TX_ACTIVE(up)) {
    [...]
    +		} else {
    [...]

    ERROR: else should follow close brace '}'
    torvalds#378: FILE: drivers/tty/serial/sunzilog.c:378:
    +			}
    +			else if (r1 & PAR_ERR)

    ERROR: code indent should use tabs where possible
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: please, no space before tabs
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: line over 80 characters
    torvalds#440: FILE: drivers/tty/serial/sunzilog.c:440:
    +		/* The Zilog just gives us an interrupt when DCD/CTS/etc. change.

    WARNING: line over 80 characters
    torvalds#441: FILE: drivers/tty/serial/sunzilog.c:441:
    +		 * But it does not tell us which bit has changed, we have to keep

    WARNING: Missing a blank line after declarations
    torvalds#464: FILE: drivers/tty/serial/sunzilog.c:464:
    +		unsigned char status = readb(&channel->control);
    +		ZSDELAY();

    WARNING: line over 80 characters
    torvalds#468: FILE: drivers/tty/serial/sunzilog.c:468:
    +		 * It can occur because of how we do serial console writes.  It would

    WARNING: line over 80 characters
    torvalds#469: FILE: drivers/tty/serial/sunzilog.c:469:
    +		 * be nice to transmit console writes just like we normally would for

    WARNING: line over 80 characters
    torvalds#470: FILE: drivers/tty/serial/sunzilog.c:470:
    +		 * a TTY line. (ie. buffered and TX interrupt driven).  That is not

    WARNING: line over 80 characters
    torvalds#471: FILE: drivers/tty/serial/sunzilog.c:471:
    +		 * easy because console writes cannot sleep.  One solution might be

    WARNING: line over 80 characters
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    WARNING: plain inline is preferred over __inline__
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    ERROR: trailing whitespace
    torvalds#664: FILE: drivers/tty/serial/sunzilog.c:664:
    +^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#752: FILE: drivers/tty/serial/sunzilog.c:752:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#779: FILE: drivers/tty/serial/sunzilog.c:779:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    WARNING: line over 80 characters
    #999: FILE: drivers/tty/serial/sunzilog.c:999:
    +static int sunzilog_verify_port(struct uart_port *port, struct serial_struct *ser)

    WARNING: Missing a blank line after declarations
    #1142: FILE: drivers/tty/serial/sunzilog.c:1142:
    +		unsigned char val = readb(&channel->control);
    +		if (val & Tx_BUF_EMP) {

    WARNING: Prefer [subsystem eg: netdev]_info([subsystem]dev, ... then dev_info(dev, ... then pr_info(...  to printk(KERN_INFO ...
    #1230: FILE: drivers/tty/serial/sunzilog.c:1230:
    +	printk(KERN_INFO "Console: ttyS%d (SunZilog zs%d)\n",

    WARNING: braces {} are not necessary for single statement blocks
    #1383: FILE: drivers/tty/serial/sunzilog.c:1383:
    +		if (__load_zsregs(channel, up->curregs)) {
    +			up->flags |= SUNZILOG_FLAG_ESCC;
    +		}

    WARNING: quoted string split across lines
    #1493: FILE: drivers/tty/serial/sunzilog.c:1493:
    +		dev_info(&op->dev, "Keyboard at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: quoted string split across lines
    #1497: FILE: drivers/tty/serial/sunzilog.c:1497:
    +		dev_info(&op->dev, "Mouse at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: Missing a blank line after declarations
    #1581: FILE: drivers/tty/serial/sunzilog.c:1581:
    +		struct uart_sunzilog_port *up = sunzilog_irq_chain;
    +		err = request_irq(zilog_irq, sunzilog_interrupt, IRQF_SHARED,

    WARNING: line over 80 characters
    #1590: FILE: drivers/tty/serial/sunzilog.c:1590:
    +			/* printk (KERN_INFO "Enable IRQ for ZILOG Hardware %p\n", up); */

    WARNING: line over 80 characters
    #1627: FILE: drivers/tty/serial/sunzilog.c:1627:
    +			/* printk (KERN_INFO "Disable IRQ for ZILOG Hardware %p\n", up); */

    ERROR: trailing statements should be on next line
    #1248: FILE: drivers/tty/serial/sunzilog.c:1248:
    +	case B150: baud = 150; break;

    ERROR: trailing statements should be on next line
    #1249: FILE: drivers/tty/serial/sunzilog.c:1249:
    +	case B300: baud = 300; break;

    ERROR: trailing statements should be on next line
    #1250: FILE: drivers/tty/serial/sunzilog.c:1250:
    +	case B600: baud = 600; break;

    ERROR: trailing statements should be on next line
    #1251: FILE: drivers/tty/serial/sunzilog.c:1251:
    +	case B1200: baud = 1200; break;

    ERROR: trailing statements should be on next line
    #1252: FILE: drivers/tty/serial/sunzilog.c:1252:
    +	case B2400: baud = 2400; break;

    ERROR: trailing statements should be on next line
    #1253: FILE: drivers/tty/serial/sunzilog.c:1253:
    +	case B4800: baud = 4800; break;

    ERROR: trailing statements should be on next line
    #1254: FILE: drivers/tty/serial/sunzilog.c:1254:
    +	default: case B9600: baud = 9600; break;

    ERROR: trailing statements should be on next line
    #1255: FILE: drivers/tty/serial/sunzilog.c:1255:
    +	case B19200: baud = 19200; break;

    ERROR: trailing statements should be on next line
    #1256: FILE: drivers/tty/serial/sunzilog.c:1256:
    +	case B38400: baud = 38400; break;

Signed-off-by: Enrico Weigelt <info@metux.net>
metux added a commit to metux/linux that referenced this pull request Feb 7, 2021
Fix checkpatch warnings:

    WARNING: Use #include <linux/io.h> instead of <asm/io.h>
    torvalds#38: FILE: drivers/tty/serial/sunzilog.c:38:
    +#include <asm/io.h>

    WARNING: line over 80 characters
    torvalds#109: FILE: drivers/tty/serial/sunzilog.c:109:
    +#define ZILOG_CHANNEL_FROM_PORT(PORT)	((struct zilog_channel __iomem *)((PORT)->membase))

    WARNING: line over 80 characters
    torvalds#116: FILE: drivers/tty/serial/sunzilog.c:116:
    +#define ZS_WANTS_MODEM_STATUS(UP)	((UP)->flags & SUNZILOG_FLAG_MODEM_STATUS)

    WARNING: line over 80 characters
    torvalds#179: FILE: drivers/tty/serial/sunzilog.c:179:
    +static int __load_zsregs(struct zilog_channel __iomem *channel, unsigned char *regs)

    WARNING: Missing a blank line after declarations
    torvalds#188: FILE: drivers/tty/serial/sunzilog.c:188:
    +		unsigned char stat = read_zsreg(channel, R1);
    +		if (stat & ALL_SNT)

    ERROR: trailing whitespace
    torvalds#231: FILE: drivers/tty/serial/sunzilog.c:231:
    +^I$

    WARNING: braces {} are not necessary for any arm of this statement
    torvalds#276: FILE: drivers/tty/serial/sunzilog.c:276:
    +		if (ZS_TX_ACTIVE(up)) {
    [...]
    +		} else {
    [...]

    ERROR: else should follow close brace '}'
    torvalds#378: FILE: drivers/tty/serial/sunzilog.c:378:
    +			}
    +			else if (r1 & PAR_ERR)

    ERROR: code indent should use tabs where possible
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: please, no space before tabs
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: line over 80 characters
    torvalds#440: FILE: drivers/tty/serial/sunzilog.c:440:
    +		/* The Zilog just gives us an interrupt when DCD/CTS/etc. change.

    WARNING: line over 80 characters
    torvalds#441: FILE: drivers/tty/serial/sunzilog.c:441:
    +		 * But it does not tell us which bit has changed, we have to keep

    WARNING: Missing a blank line after declarations
    torvalds#464: FILE: drivers/tty/serial/sunzilog.c:464:
    +		unsigned char status = readb(&channel->control);
    +		ZSDELAY();

    WARNING: line over 80 characters
    torvalds#468: FILE: drivers/tty/serial/sunzilog.c:468:
    +		 * It can occur because of how we do serial console writes.  It would

    WARNING: line over 80 characters
    torvalds#469: FILE: drivers/tty/serial/sunzilog.c:469:
    +		 * be nice to transmit console writes just like we normally would for

    WARNING: line over 80 characters
    torvalds#470: FILE: drivers/tty/serial/sunzilog.c:470:
    +		 * a TTY line. (ie. buffered and TX interrupt driven).  That is not

    WARNING: line over 80 characters
    torvalds#471: FILE: drivers/tty/serial/sunzilog.c:471:
    +		 * easy because console writes cannot sleep.  One solution might be

    WARNING: line over 80 characters
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    WARNING: plain inline is preferred over __inline__
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    ERROR: trailing whitespace
    torvalds#664: FILE: drivers/tty/serial/sunzilog.c:664:
    +^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#752: FILE: drivers/tty/serial/sunzilog.c:752:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#779: FILE: drivers/tty/serial/sunzilog.c:779:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    WARNING: line over 80 characters
    #999: FILE: drivers/tty/serial/sunzilog.c:999:
    +static int sunzilog_verify_port(struct uart_port *port, struct serial_struct *ser)

    WARNING: Missing a blank line after declarations
    #1142: FILE: drivers/tty/serial/sunzilog.c:1142:
    +		unsigned char val = readb(&channel->control);
    +		if (val & Tx_BUF_EMP) {

    WARNING: Prefer [subsystem eg: netdev]_info([subsystem]dev, ... then dev_info(dev, ... then pr_info(...  to printk(KERN_INFO ...
    #1230: FILE: drivers/tty/serial/sunzilog.c:1230:
    +	printk(KERN_INFO "Console: ttyS%d (SunZilog zs%d)\n",

    WARNING: braces {} are not necessary for single statement blocks
    #1383: FILE: drivers/tty/serial/sunzilog.c:1383:
    +		if (__load_zsregs(channel, up->curregs)) {
    +			up->flags |= SUNZILOG_FLAG_ESCC;
    +		}

    WARNING: quoted string split across lines
    #1493: FILE: drivers/tty/serial/sunzilog.c:1493:
    +		dev_info(&op->dev, "Keyboard at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: quoted string split across lines
    #1497: FILE: drivers/tty/serial/sunzilog.c:1497:
    +		dev_info(&op->dev, "Mouse at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: Missing a blank line after declarations
    #1581: FILE: drivers/tty/serial/sunzilog.c:1581:
    +		struct uart_sunzilog_port *up = sunzilog_irq_chain;
    +		err = request_irq(zilog_irq, sunzilog_interrupt, IRQF_SHARED,

    WARNING: line over 80 characters
    #1590: FILE: drivers/tty/serial/sunzilog.c:1590:
    +			/* printk (KERN_INFO "Enable IRQ for ZILOG Hardware %p\n", up); */

    WARNING: line over 80 characters
    #1627: FILE: drivers/tty/serial/sunzilog.c:1627:
    +			/* printk (KERN_INFO "Disable IRQ for ZILOG Hardware %p\n", up); */

    ERROR: trailing statements should be on next line
    #1248: FILE: drivers/tty/serial/sunzilog.c:1248:
    +	case B150: baud = 150; break;

    ERROR: trailing statements should be on next line
    #1249: FILE: drivers/tty/serial/sunzilog.c:1249:
    +	case B300: baud = 300; break;

    ERROR: trailing statements should be on next line
    #1250: FILE: drivers/tty/serial/sunzilog.c:1250:
    +	case B600: baud = 600; break;

    ERROR: trailing statements should be on next line
    #1251: FILE: drivers/tty/serial/sunzilog.c:1251:
    +	case B1200: baud = 1200; break;

    ERROR: trailing statements should be on next line
    #1252: FILE: drivers/tty/serial/sunzilog.c:1252:
    +	case B2400: baud = 2400; break;

    ERROR: trailing statements should be on next line
    #1253: FILE: drivers/tty/serial/sunzilog.c:1253:
    +	case B4800: baud = 4800; break;

    ERROR: trailing statements should be on next line
    #1254: FILE: drivers/tty/serial/sunzilog.c:1254:
    +	default: case B9600: baud = 9600; break;

    ERROR: trailing statements should be on next line
    #1255: FILE: drivers/tty/serial/sunzilog.c:1255:
    +	case B19200: baud = 19200; break;

    ERROR: trailing statements should be on next line
    #1256: FILE: drivers/tty/serial/sunzilog.c:1256:
    +	case B38400: baud = 38400; break;

Signed-off-by: Enrico Weigelt <info@metux.net>
metux added a commit to metux/linux that referenced this pull request Feb 7, 2021
Fix checkpatch warnings:

    WARNING: Use #include <linux/io.h> instead of <asm/io.h>
    torvalds#38: FILE: drivers/tty/serial/sunzilog.c:38:
    +#include <asm/io.h>

    WARNING: line over 80 characters
    torvalds#109: FILE: drivers/tty/serial/sunzilog.c:109:
    +#define ZILOG_CHANNEL_FROM_PORT(PORT)	((struct zilog_channel __iomem *)((PORT)->membase))

    WARNING: line over 80 characters
    torvalds#116: FILE: drivers/tty/serial/sunzilog.c:116:
    +#define ZS_WANTS_MODEM_STATUS(UP)	((UP)->flags & SUNZILOG_FLAG_MODEM_STATUS)

    WARNING: line over 80 characters
    torvalds#179: FILE: drivers/tty/serial/sunzilog.c:179:
    +static int __load_zsregs(struct zilog_channel __iomem *channel, unsigned char *regs)

    WARNING: Missing a blank line after declarations
    torvalds#188: FILE: drivers/tty/serial/sunzilog.c:188:
    +		unsigned char stat = read_zsreg(channel, R1);
    +		if (stat & ALL_SNT)

    ERROR: trailing whitespace
    torvalds#231: FILE: drivers/tty/serial/sunzilog.c:231:
    +^I$

    WARNING: braces {} are not necessary for any arm of this statement
    torvalds#276: FILE: drivers/tty/serial/sunzilog.c:276:
    +		if (ZS_TX_ACTIVE(up)) {
    [...]
    +		} else {
    [...]

    ERROR: else should follow close brace '}'
    torvalds#378: FILE: drivers/tty/serial/sunzilog.c:378:
    +			}
    +			else if (r1 & PAR_ERR)

    ERROR: code indent should use tabs where possible
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: please, no space before tabs
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: line over 80 characters
    torvalds#440: FILE: drivers/tty/serial/sunzilog.c:440:
    +		/* The Zilog just gives us an interrupt when DCD/CTS/etc. change.

    WARNING: line over 80 characters
    torvalds#441: FILE: drivers/tty/serial/sunzilog.c:441:
    +		 * But it does not tell us which bit has changed, we have to keep

    WARNING: Missing a blank line after declarations
    torvalds#464: FILE: drivers/tty/serial/sunzilog.c:464:
    +		unsigned char status = readb(&channel->control);
    +		ZSDELAY();

    WARNING: line over 80 characters
    torvalds#468: FILE: drivers/tty/serial/sunzilog.c:468:
    +		 * It can occur because of how we do serial console writes.  It would

    WARNING: line over 80 characters
    torvalds#469: FILE: drivers/tty/serial/sunzilog.c:469:
    +		 * be nice to transmit console writes just like we normally would for

    WARNING: line over 80 characters
    torvalds#470: FILE: drivers/tty/serial/sunzilog.c:470:
    +		 * a TTY line. (ie. buffered and TX interrupt driven).  That is not

    WARNING: line over 80 characters
    torvalds#471: FILE: drivers/tty/serial/sunzilog.c:471:
    +		 * easy because console writes cannot sleep.  One solution might be

    WARNING: line over 80 characters
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    WARNING: plain inline is preferred over __inline__
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    ERROR: trailing whitespace
    torvalds#664: FILE: drivers/tty/serial/sunzilog.c:664:
    +^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#752: FILE: drivers/tty/serial/sunzilog.c:752:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#779: FILE: drivers/tty/serial/sunzilog.c:779:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    WARNING: line over 80 characters
    #999: FILE: drivers/tty/serial/sunzilog.c:999:
    +static int sunzilog_verify_port(struct uart_port *port, struct serial_struct *ser)

    WARNING: Missing a blank line after declarations
    #1142: FILE: drivers/tty/serial/sunzilog.c:1142:
    +		unsigned char val = readb(&channel->control);
    +		if (val & Tx_BUF_EMP) {

    WARNING: Prefer [subsystem eg: netdev]_info([subsystem]dev, ... then dev_info(dev, ... then pr_info(...  to printk(KERN_INFO ...
    #1230: FILE: drivers/tty/serial/sunzilog.c:1230:
    +	printk(KERN_INFO "Console: ttyS%d (SunZilog zs%d)\n",

    WARNING: braces {} are not necessary for single statement blocks
    #1383: FILE: drivers/tty/serial/sunzilog.c:1383:
    +		if (__load_zsregs(channel, up->curregs)) {
    +			up->flags |= SUNZILOG_FLAG_ESCC;
    +		}

    WARNING: quoted string split across lines
    #1493: FILE: drivers/tty/serial/sunzilog.c:1493:
    +		dev_info(&op->dev, "Keyboard at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: quoted string split across lines
    #1497: FILE: drivers/tty/serial/sunzilog.c:1497:
    +		dev_info(&op->dev, "Mouse at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: Missing a blank line after declarations
    #1581: FILE: drivers/tty/serial/sunzilog.c:1581:
    +		struct uart_sunzilog_port *up = sunzilog_irq_chain;
    +		err = request_irq(zilog_irq, sunzilog_interrupt, IRQF_SHARED,

    WARNING: line over 80 characters
    #1590: FILE: drivers/tty/serial/sunzilog.c:1590:
    +			/* printk (KERN_INFO "Enable IRQ for ZILOG Hardware %p\n", up); */

    WARNING: line over 80 characters
    #1627: FILE: drivers/tty/serial/sunzilog.c:1627:
    +			/* printk (KERN_INFO "Disable IRQ for ZILOG Hardware %p\n", up); */

    ERROR: trailing statements should be on next line
    #1248: FILE: drivers/tty/serial/sunzilog.c:1248:
    +	case B150: baud = 150; break;

    ERROR: trailing statements should be on next line
    #1249: FILE: drivers/tty/serial/sunzilog.c:1249:
    +	case B300: baud = 300; break;

    ERROR: trailing statements should be on next line
    #1250: FILE: drivers/tty/serial/sunzilog.c:1250:
    +	case B600: baud = 600; break;

    ERROR: trailing statements should be on next line
    #1251: FILE: drivers/tty/serial/sunzilog.c:1251:
    +	case B1200: baud = 1200; break;

    ERROR: trailing statements should be on next line
    #1252: FILE: drivers/tty/serial/sunzilog.c:1252:
    +	case B2400: baud = 2400; break;

    ERROR: trailing statements should be on next line
    #1253: FILE: drivers/tty/serial/sunzilog.c:1253:
    +	case B4800: baud = 4800; break;

    ERROR: trailing statements should be on next line
    #1254: FILE: drivers/tty/serial/sunzilog.c:1254:
    +	default: case B9600: baud = 9600; break;

    ERROR: trailing statements should be on next line
    #1255: FILE: drivers/tty/serial/sunzilog.c:1255:
    +	case B19200: baud = 19200; break;

    ERROR: trailing statements should be on next line
    #1256: FILE: drivers/tty/serial/sunzilog.c:1256:
    +	case B38400: baud = 38400; break;

Signed-off-by: Enrico Weigelt <info@metux.net>
metux added a commit to metux/linux that referenced this pull request Feb 8, 2021
Fix checkpatch warnings:

    WARNING: Use #include <linux/io.h> instead of <asm/io.h>
    torvalds#38: FILE: drivers/tty/serial/sunzilog.c:38:
    +#include <asm/io.h>

    WARNING: line over 80 characters
    torvalds#109: FILE: drivers/tty/serial/sunzilog.c:109:
    +#define ZILOG_CHANNEL_FROM_PORT(PORT)	((struct zilog_channel __iomem *)((PORT)->membase))

    WARNING: line over 80 characters
    torvalds#116: FILE: drivers/tty/serial/sunzilog.c:116:
    +#define ZS_WANTS_MODEM_STATUS(UP)	((UP)->flags & SUNZILOG_FLAG_MODEM_STATUS)

    WARNING: line over 80 characters
    torvalds#179: FILE: drivers/tty/serial/sunzilog.c:179:
    +static int __load_zsregs(struct zilog_channel __iomem *channel, unsigned char *regs)

    WARNING: Missing a blank line after declarations
    torvalds#188: FILE: drivers/tty/serial/sunzilog.c:188:
    +		unsigned char stat = read_zsreg(channel, R1);
    +		if (stat & ALL_SNT)

    ERROR: trailing whitespace
    torvalds#231: FILE: drivers/tty/serial/sunzilog.c:231:
    +^I$

    WARNING: braces {} are not necessary for any arm of this statement
    torvalds#276: FILE: drivers/tty/serial/sunzilog.c:276:
    +		if (ZS_TX_ACTIVE(up)) {
    [...]
    +		} else {
    [...]

    ERROR: else should follow close brace '}'
    torvalds#378: FILE: drivers/tty/serial/sunzilog.c:378:
    +			}
    +			else if (r1 & PAR_ERR)

    ERROR: code indent should use tabs where possible
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: please, no space before tabs
    torvalds#397: FILE: drivers/tty/serial/sunzilog.c:397:
    +^I^I    ^Itty_insert_flip_char(port, ch, flag);$

    WARNING: line over 80 characters
    torvalds#440: FILE: drivers/tty/serial/sunzilog.c:440:
    +		/* The Zilog just gives us an interrupt when DCD/CTS/etc. change.

    WARNING: line over 80 characters
    torvalds#441: FILE: drivers/tty/serial/sunzilog.c:441:
    +		 * But it does not tell us which bit has changed, we have to keep

    WARNING: Missing a blank line after declarations
    torvalds#464: FILE: drivers/tty/serial/sunzilog.c:464:
    +		unsigned char status = readb(&channel->control);
    +		ZSDELAY();

    WARNING: line over 80 characters
    torvalds#468: FILE: drivers/tty/serial/sunzilog.c:468:
    +		 * It can occur because of how we do serial console writes.  It would

    WARNING: line over 80 characters
    torvalds#469: FILE: drivers/tty/serial/sunzilog.c:469:
    +		 * be nice to transmit console writes just like we normally would for

    WARNING: line over 80 characters
    torvalds#470: FILE: drivers/tty/serial/sunzilog.c:470:
    +		 * a TTY line. (ie. buffered and TX interrupt driven).  That is not

    WARNING: line over 80 characters
    torvalds#471: FILE: drivers/tty/serial/sunzilog.c:471:
    +		 * easy because console writes cannot sleep.  One solution might be

    WARNING: line over 80 characters
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    WARNING: plain inline is preferred over __inline__
    torvalds#593: FILE: drivers/tty/serial/sunzilog.c:593:
    +static __inline__ unsigned char sunzilog_read_channel_status(struct uart_port *port)

    ERROR: trailing whitespace
    torvalds#664: FILE: drivers/tty/serial/sunzilog.c:664:
    +^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#752: FILE: drivers/tty/serial/sunzilog.c:752:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    ERROR: trailing whitespace
    torvalds#779: FILE: drivers/tty/serial/sunzilog.c:779:
    +^I^I/* NOTE: Not subject to 'transmitter active' rule.  */ $

    WARNING: line over 80 characters
    #999: FILE: drivers/tty/serial/sunzilog.c:999:
    +static int sunzilog_verify_port(struct uart_port *port, struct serial_struct *ser)

    WARNING: Missing a blank line after declarations
    #1142: FILE: drivers/tty/serial/sunzilog.c:1142:
    +		unsigned char val = readb(&channel->control);
    +		if (val & Tx_BUF_EMP) {

    WARNING: Prefer [subsystem eg: netdev]_info([subsystem]dev, ... then dev_info(dev, ... then pr_info(...  to printk(KERN_INFO ...
    #1230: FILE: drivers/tty/serial/sunzilog.c:1230:
    +	printk(KERN_INFO "Console: ttyS%d (SunZilog zs%d)\n",

    WARNING: braces {} are not necessary for single statement blocks
    #1383: FILE: drivers/tty/serial/sunzilog.c:1383:
    +		if (__load_zsregs(channel, up->curregs)) {
    +			up->flags |= SUNZILOG_FLAG_ESCC;
    +		}

    WARNING: quoted string split across lines
    #1493: FILE: drivers/tty/serial/sunzilog.c:1493:
    +		dev_info(&op->dev, "Keyboard at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: quoted string split across lines
    #1497: FILE: drivers/tty/serial/sunzilog.c:1497:
    +		dev_info(&op->dev, "Mouse at MMIO 0x%llx (irq = %d) "
    +		       "is a %s\n",

    WARNING: Missing a blank line after declarations
    #1581: FILE: drivers/tty/serial/sunzilog.c:1581:
    +		struct uart_sunzilog_port *up = sunzilog_irq_chain;
    +		err = request_irq(zilog_irq, sunzilog_interrupt, IRQF_SHARED,

    WARNING: line over 80 characters
    #1590: FILE: drivers/tty/serial/sunzilog.c:1590:
    +			/* printk (KERN_INFO "Enable IRQ for ZILOG Hardware %p\n", up); */

    WARNING: line over 80 characters
    #1627: FILE: drivers/tty/serial/sunzilog.c:1627:
    +			/* printk (KERN_INFO "Disable IRQ for ZILOG Hardware %p\n", up); */

    ERROR: trailing statements should be on next line
    #1248: FILE: drivers/tty/serial/sunzilog.c:1248:
    +	case B150: baud = 150; break;

    ERROR: trailing statements should be on next line
    #1249: FILE: drivers/tty/serial/sunzilog.c:1249:
    +	case B300: baud = 300; break;

    ERROR: trailing statements should be on next line
    #1250: FILE: drivers/tty/serial/sunzilog.c:1250:
    +	case B600: baud = 600; break;

    ERROR: trailing statements should be on next line
    #1251: FILE: drivers/tty/serial/sunzilog.c:1251:
    +	case B1200: baud = 1200; break;

    ERROR: trailing statements should be on next line
    #1252: FILE: drivers/tty/serial/sunzilog.c:1252:
    +	case B2400: baud = 2400; break;

    ERROR: trailing statements should be on next line
    #1253: FILE: drivers/tty/serial/sunzilog.c:1253:
    +	case B4800: baud = 4800; break;

    ERROR: trailing statements should be on next line
    #1254: FILE: drivers/tty/serial/sunzilog.c:1254:
    +	default: case B9600: baud = 9600; break;

    ERROR: trailing statements should be on next line
    #1255: FILE: drivers/tty/serial/sunzilog.c:1255:
    +	case B19200: baud = 19200; break;

    ERROR: trailing statements should be on next line
    #1256: FILE: drivers/tty/serial/sunzilog.c:1256:
    +	case B38400: baud = 38400; break;

Signed-off-by: Enrico Weigelt <info@metux.net>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Mar 15, 2021
This commit fixes the following checkpatch.pl errors:

    ERROR:POINTER_LOCATION: "foo *		bar" should be "foo *bar"
    torvalds#14: FILE: ./hal/odm_DIG.c:14:
    +	struct DM_ODM_T *		pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#30: FILE: ./hal/odm_DIG.c:30:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#41: FILE: ./hal/odm_DIG.c:41:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#51: FILE: ./hal/odm_DIG.c:51:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#59: FILE: ./hal/odm_DIG.c:59:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#72: FILE: ./hal/odm_DIG.c:72:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#136: FILE: ./hal/odm_DIG.c:136:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#208: FILE: ./hal/odm_DIG.c:208:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#236: FILE: ./hal/odm_DIG.c:236:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#325: FILE: ./hal/odm_DIG.c:325:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#326: FILE: ./hal/odm_DIG.c:326:
    +	struct DIG_T * pDM_DigTable = &pDM_Odm->DM_DigTable;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#365: FILE: ./hal/odm_DIG.c:365:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#366: FILE: ./hal/odm_DIG.c:366:
    +	struct DIG_T * pDM_DigTable = &pDM_Odm->DM_DigTable;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#438: FILE: ./hal/odm_DIG.c:438:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#469: FILE: ./hal/odm_DIG.c:469:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#470: FILE: ./hal/odm_DIG.c:470:
    +	struct DIG_T * pDM_DigTable = &pDM_Odm->DM_DigTable;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#507: FILE: ./hal/odm_DIG.c:507:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#510: FILE: ./hal/odm_DIG.c:510:
    +	struct DIG_T * pDM_DigTable = &pDM_Odm->DM_DigTable;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#826: FILE: ./hal/odm_DIG.c:826:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#895: FILE: ./hal/odm_DIG.c:895:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#896: FILE: ./hal/odm_DIG.c:896:
    +	struct false_ALARM_STATISTICS * FalseAlmCnt = &(pDM_Odm->FalseAlmCnt);

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #1065: FILE: ./hal/odm_DIG.c:1065:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #1081: FILE: ./hal/odm_DIG.c:1081:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #1082: FILE: ./hal/odm_DIG.c:1082:
    +	struct DIG_T * pDM_DigTable = &pDM_Odm->DM_DigTable;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #1083: FILE: ./hal/odm_DIG.c:1083:
    +	struct false_ALARM_STATISTICS * pFalseAlmCnt = &(pDM_Odm->FalseAlmCnt);

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #1137: FILE: ./hal/odm_DIG.c:1137:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #1138: FILE: ./hal/odm_DIG.c:1138:
    +	struct false_ALARM_STATISTICS * FalseAlmCnt = &(pDM_Odm->FalseAlmCnt);

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #1198: FILE: ./hal/odm_DIG.c:1198:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #1199: FILE: ./hal/odm_DIG.c:1199:
    +	struct DIG_T * pDM_DigTable = &pDM_Odm->DM_DigTable;

Signed-off-by: Marco Cesati <marcocesati@gmail.com>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Mar 16, 2021
This commit fixes the following checkpatch.pl errors:

    ERROR:POINTER_LOCATION: "foo *		bar" should be "foo *bar"
    torvalds#14: FILE: ./hal/odm_DIG.c:14:
    +	struct DM_ODM_T *		pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#30: FILE: ./hal/odm_DIG.c:30:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#41: FILE: ./hal/odm_DIG.c:41:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#51: FILE: ./hal/odm_DIG.c:51:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#59: FILE: ./hal/odm_DIG.c:59:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#72: FILE: ./hal/odm_DIG.c:72:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#136: FILE: ./hal/odm_DIG.c:136:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#208: FILE: ./hal/odm_DIG.c:208:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#236: FILE: ./hal/odm_DIG.c:236:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#325: FILE: ./hal/odm_DIG.c:325:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#326: FILE: ./hal/odm_DIG.c:326:
    +	struct DIG_T * pDM_DigTable = &pDM_Odm->DM_DigTable;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#365: FILE: ./hal/odm_DIG.c:365:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#366: FILE: ./hal/odm_DIG.c:366:
    +	struct DIG_T * pDM_DigTable = &pDM_Odm->DM_DigTable;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#438: FILE: ./hal/odm_DIG.c:438:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#469: FILE: ./hal/odm_DIG.c:469:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#470: FILE: ./hal/odm_DIG.c:470:
    +	struct DIG_T * pDM_DigTable = &pDM_Odm->DM_DigTable;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#507: FILE: ./hal/odm_DIG.c:507:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#510: FILE: ./hal/odm_DIG.c:510:
    +	struct DIG_T * pDM_DigTable = &pDM_Odm->DM_DigTable;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#826: FILE: ./hal/odm_DIG.c:826:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#895: FILE: ./hal/odm_DIG.c:895:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#896: FILE: ./hal/odm_DIG.c:896:
    +	struct false_ALARM_STATISTICS * FalseAlmCnt = &(pDM_Odm->FalseAlmCnt);

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #1065: FILE: ./hal/odm_DIG.c:1065:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #1081: FILE: ./hal/odm_DIG.c:1081:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #1082: FILE: ./hal/odm_DIG.c:1082:
    +	struct DIG_T * pDM_DigTable = &pDM_Odm->DM_DigTable;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #1083: FILE: ./hal/odm_DIG.c:1083:
    +	struct false_ALARM_STATISTICS * pFalseAlmCnt = &(pDM_Odm->FalseAlmCnt);

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #1137: FILE: ./hal/odm_DIG.c:1137:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #1138: FILE: ./hal/odm_DIG.c:1138:
    +	struct false_ALARM_STATISTICS * FalseAlmCnt = &(pDM_Odm->FalseAlmCnt);

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #1198: FILE: ./hal/odm_DIG.c:1198:
    +	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #1199: FILE: ./hal/odm_DIG.c:1199:
    +	struct DIG_T * pDM_DigTable = &pDM_Odm->DM_DigTable;

Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Marco Cesati <marcocesati@gmail.com>
Link: https://lore.kernel.org/r/20210315170618.2566-24-marcocesati@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Nov 24, 2021
[ Upstream commit bdc1bbd ]

The assoc_timer takes the pmlmepriv->lock and various functions which
take the pmlmepriv->scanned_queue.lock first take the pmlmepriv->lock,
this means that we cannot have code which waits for the timer
(timer_del_sync) while holding the pmlmepriv->scanned_queue.lock
to avoid a triangle deadlock:

[  363.139361] ======================================================
[  363.139377] WARNING: possible circular locking dependency detected
[  363.139396] 5.15.0-rc1+ torvalds#470 Tainted: G         C  E
[  363.139413] ------------------------------------------------------
[  363.139424] RTW_CMD_THREAD/2466 is trying to acquire lock:
[  363.139441] ffffbacd00699038 (&pmlmepriv->lock){+.-.}-{2:2}, at: _rtw_join_timeout_handler+0x3c/0x160 [r8723bs]
[  363.139598]
               but task is already holding lock:
[  363.139610] ffffbacd00128ea0 ((&pmlmepriv->assoc_timer)){+.-.}-{0:0}, at: call_timer_fn+0x5/0x260
[  363.139673]
               which lock already depends on the new lock.

[  363.139684]
               the existing dependency chain (in reverse order) is:
[  363.139696]
               -> #2 ((&pmlmepriv->assoc_timer)){+.-.}-{0:0}:
[  363.139734]        del_timer_sync+0x59/0x100
[  363.139762]        rtw_joinbss_event_prehandle+0x342/0x640 [r8723bs]
[  363.139870]        report_join_res+0xdf/0x110 [r8723bs]
[  363.139980]        OnAssocRsp+0x17a/0x200 [r8723bs]
[  363.140092]        rtw_recv_entry+0x190/0x1120 [r8723bs]
[  363.140209]        rtl8723b_process_phy_info+0x3f9/0x750 [r8723bs]
[  363.140318]        tasklet_action_common.constprop.0+0xe8/0x110
[  363.140345]        __do_softirq+0xde/0x485
[  363.140372]        __irq_exit_rcu+0xd0/0x100
[  363.140393]        irq_exit_rcu+0xa/0x20
[  363.140413]        common_interrupt+0x83/0xa0
[  363.140440]        asm_common_interrupt+0x1e/0x40
[  363.140463]        finish_task_switch.isra.0+0x157/0x3d0
[  363.140492]        __schedule+0x447/0x1880
[  363.140516]        schedule+0x59/0xc0
[  363.140537]        smpboot_thread_fn+0x161/0x1c0
[  363.140565]        kthread+0x143/0x160
[  363.140585]        ret_from_fork+0x22/0x30
[  363.140614]
               -> #1 (&pmlmepriv->scanned_queue.lock){+.-.}-{2:2}:
[  363.140653]        _raw_spin_lock_bh+0x34/0x40
[  363.140675]        rtw_free_network_queue+0x31/0x80 [r8723bs]
[  363.140776]        rtw_sitesurvey_cmd+0x79/0x1e0 [r8723bs]
[  363.140869]        rtw_cfg80211_surveydone_event_callback+0x3cf/0x470 [r8723bs]
[  363.140973]        rdev_scan+0x42/0x1a0 [cfg80211]
[  363.141307]        nl80211_trigger_scan+0x566/0x660 [cfg80211]
[  363.141635]        genl_family_rcv_msg_doit+0xcd/0x110
[  363.141661]        genl_rcv_msg+0xce/0x1c0
[  363.141680]        netlink_rcv_skb+0x50/0xf0
[  363.141699]        genl_rcv+0x24/0x40
[  363.141717]        netlink_unicast+0x16d/0x230
[  363.141736]        netlink_sendmsg+0x22b/0x450
[  363.141755]        sock_sendmsg+0x5e/0x60
[  363.141781]        ____sys_sendmsg+0x22f/0x270
[  363.141803]        ___sys_sendmsg+0x81/0xc0
[  363.141828]        __sys_sendmsg+0x49/0x80
[  363.141851]        do_syscall_64+0x3b/0x90
[  363.141873]        entry_SYSCALL_64_after_hwframe+0x44/0xae
[  363.141895]
               -> #0 (&pmlmepriv->lock){+.-.}-{2:2}:
[  363.141930]        __lock_acquire+0x1158/0x1de0
[  363.141954]        lock_acquire+0xb5/0x2b0
[  363.141974]        _raw_spin_lock_bh+0x34/0x40
[  363.141993]        _rtw_join_timeout_handler+0x3c/0x160 [r8723bs]
[  363.142097]        call_timer_fn+0x94/0x260
[  363.142122]        __run_timers.part.0+0x1bf/0x290
[  363.142147]        run_timer_softirq+0x26/0x50
[  363.142171]        __do_softirq+0xde/0x485
[  363.142193]        __irq_exit_rcu+0xd0/0x100
[  363.142215]        irq_exit_rcu+0xa/0x20
[  363.142235]        sysvec_apic_timer_interrupt+0x72/0x90
[  363.142260]        asm_sysvec_apic_timer_interrupt+0x12/0x20
[  363.142283]        __module_address.part.0+0x0/0xd0
[  363.142309]        is_module_address+0x25/0x40
[  363.142334]        static_obj+0x4f/0x60
[  363.142361]        lockdep_init_map_type+0x47/0x220
[  363.142382]        __init_swait_queue_head+0x45/0x60
[  363.142408]        mmc_wait_for_req+0x4a/0xc0 [mmc_core]
[  363.142504]        mmc_wait_for_cmd+0x55/0x70 [mmc_core]
[  363.142592]        mmc_io_rw_direct+0x75/0xe0 [mmc_core]
[  363.142691]        sdio_writeb+0x2e/0x50 [mmc_core]
[  363.142788]        _sd_cmd52_write+0x62/0x80 [r8723bs]
[  363.142885]        sd_cmd52_write+0x6c/0xb0 [r8723bs]
[  363.142981]        rtl8723bs_set_hal_ops+0x982/0x9b0 [r8723bs]
[  363.143089]        rtw_write16+0x1e/0x30 [r8723bs]
[  363.143184]        SetHwReg8723B+0xcc9/0xd30 [r8723bs]
[  363.143294]        mlmeext_joinbss_event_callback+0x17a/0x1a0 [r8723bs]
[  363.143405]        rtw_joinbss_event_callback+0x11/0x20 [r8723bs]
[  363.143507]        mlme_evt_hdl+0x4d/0x70 [r8723bs]
[  363.143620]        rtw_cmd_thread+0x168/0x3c0 [r8723bs]
[  363.143712]        kthread+0x143/0x160
[  363.143732]        ret_from_fork+0x22/0x30
[  363.143757]
               other info that might help us debug this:

[  363.143768] Chain exists of:
                 &pmlmepriv->lock --> &pmlmepriv->scanned_queue.lock --> (&pmlmepriv->assoc_timer)

[  363.143809]  Possible unsafe locking scenario:

[  363.143819]        CPU0                    CPU1
[  363.143831]        ----                    ----
[  363.143841]   lock((&pmlmepriv->assoc_timer));
[  363.143862]                                lock(&pmlmepriv->scanned_queue.lock);
[  363.143882]                                lock((&pmlmepriv->assoc_timer));
[  363.143902]   lock(&pmlmepriv->lock);
[  363.143921]
                *** DEADLOCK ***

Make rtw_joinbss_event_prehandle() release the scanned_queue.lock before
it deletes the timer to avoid this (it is still holding pmlmepriv->lock
protecting against racing the timer).

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210920145502.155454-3-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Nov 24, 2021
[ Upstream commit a7ac783 ]

Lockdep complains about rtw_free_assoc_resources() taking the sta_hash_lock
followed by it calling rtw_free_stainfo() which takes xmitpriv->lock.
While the rtl8723bs_xmit_thread takes the sta_hash_lock while already
holding the xmitpriv->lock:

[  103.849756] ======================================================
[  103.849761] WARNING: possible circular locking dependency detected
[  103.849767] 5.15.0-rc1+ torvalds#470 Tainted: G         C  E
[  103.849773] ------------------------------------------------------
[  103.849776] wpa_supplicant/695 is trying to acquire lock:
[  103.849781] ffffa5d0c0562b00 (&pxmitpriv->lock){+.-.}-{2:2}, at: rtw_free_stainfo+0x8a/0x510 [r8723bs]
[  103.849840]
               but task is already holding lock:
[  103.849843] ffffa5d0c05636a8 (&pstapriv->sta_hash_lock){+.-.}-{2:2}, at: rtw_free_assoc_resources+0x48/0x110 [r8723bs]
[  103.849881]
               which lock already depends on the new lock.

[  103.849884]
               the existing dependency chain (in reverse order) is:
[  103.849887]
               -> #1 (&pstapriv->sta_hash_lock){+.-.}-{2:2}:
[  103.849898]        _raw_spin_lock_bh+0x34/0x40
[  103.849913]        rtw_get_stainfo+0x93/0x110 [r8723bs]
[  103.849948]        rtw_make_wlanhdr+0x14a/0x270 [r8723bs]
[  103.849983]        rtw_xmitframe_coalesce+0x5c/0x6c0 [r8723bs]
[  103.850019]        rtl8723bs_xmit_thread+0x4ac/0x620 [r8723bs]
[  103.850050]        kthread+0x143/0x160
[  103.850058]        ret_from_fork+0x22/0x30
[  103.850067]
               -> #0 (&pxmitpriv->lock){+.-.}-{2:2}:
[  103.850077]        __lock_acquire+0x1158/0x1de0
[  103.850084]        lock_acquire+0xb5/0x2b0
[  103.850090]        _raw_spin_lock_bh+0x34/0x40
[  103.850095]        rtw_free_stainfo+0x8a/0x510 [r8723bs]
[  103.850130]        rtw_free_assoc_resources+0x53/0x110 [r8723bs]
[  103.850159]        PHY_IQCalibrate_8723B+0x122b/0x36a0 [r8723bs]
[  103.850189]        cfg80211_disconnect+0x173/0x320 [cfg80211]
[  103.850331]        nl80211_disconnect+0x6e/0xb0 [cfg80211]
[  103.850422]        genl_family_rcv_msg_doit+0xcd/0x110
[  103.850430]        genl_rcv_msg+0xce/0x1c0
[  103.850435]        netlink_rcv_skb+0x50/0xf0
[  103.850441]        genl_rcv+0x24/0x40
[  103.850446]        netlink_unicast+0x16d/0x230
[  103.850452]        netlink_sendmsg+0x22b/0x450
[  103.850457]        sock_sendmsg+0x5e/0x60
[  103.850465]        ____sys_sendmsg+0x22f/0x270
[  103.850472]        ___sys_sendmsg+0x81/0xc0
[  103.850479]        __sys_sendmsg+0x49/0x80
[  103.850485]        do_syscall_64+0x3b/0x90
[  103.850493]        entry_SYSCALL_64_after_hwframe+0x44/0xae
[  103.850500]
               other info that might help us debug this:

[  103.850504]  Possible unsafe locking scenario:

[  103.850507]        CPU0                    CPU1
[  103.850510]        ----                    ----
[  103.850512]   lock(&pstapriv->sta_hash_lock);
[  103.850518]                                lock(&pxmitpriv->lock);
[  103.850524]                                lock(&pstapriv->sta_hash_lock);
[  103.850530]   lock(&pxmitpriv->lock);
[  103.850535]
                *** DEADLOCK ***

Push the taking of sta_hash_lock down into rtw_free_stainfo(),
where the critical section is, this allows taking the lock after
rtw_free_stainfo() has released pxmitpriv->lock.

This requires changing rtw_free_all_stainfo() so that it does its freeing
in 2 steps, first moving all stainfo-s to free to a local list while
holding the sta_hash_lock and then walking that list to call
rtw_free_stainfo() on them without holding the sta_hash_lock.

Pushing the taking of sta_hash_lock down into rtw_free_stainfo(),
also fixes a whole bunch of callers of rtw_free_stainfo() which
were not holding that lock even though they should.

Note that this also fixes the deadlock from the "remove possible
deadlock when disconnect" patch in a different way. But the
changes from that patch offer a nice locking cleanup regardless.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210920145502.155454-2-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Nov 24, 2021
[ Upstream commit bdc1bbd ]

The assoc_timer takes the pmlmepriv->lock and various functions which
take the pmlmepriv->scanned_queue.lock first take the pmlmepriv->lock,
this means that we cannot have code which waits for the timer
(timer_del_sync) while holding the pmlmepriv->scanned_queue.lock
to avoid a triangle deadlock:

[  363.139361] ======================================================
[  363.139377] WARNING: possible circular locking dependency detected
[  363.139396] 5.15.0-rc1+ torvalds#470 Tainted: G         C  E
[  363.139413] ------------------------------------------------------
[  363.139424] RTW_CMD_THREAD/2466 is trying to acquire lock:
[  363.139441] ffffbacd00699038 (&pmlmepriv->lock){+.-.}-{2:2}, at: _rtw_join_timeout_handler+0x3c/0x160 [r8723bs]
[  363.139598]
               but task is already holding lock:
[  363.139610] ffffbacd00128ea0 ((&pmlmepriv->assoc_timer)){+.-.}-{0:0}, at: call_timer_fn+0x5/0x260
[  363.139673]
               which lock already depends on the new lock.

[  363.139684]
               the existing dependency chain (in reverse order) is:
[  363.139696]
               -> #2 ((&pmlmepriv->assoc_timer)){+.-.}-{0:0}:
[  363.139734]        del_timer_sync+0x59/0x100
[  363.139762]        rtw_joinbss_event_prehandle+0x342/0x640 [r8723bs]
[  363.139870]        report_join_res+0xdf/0x110 [r8723bs]
[  363.139980]        OnAssocRsp+0x17a/0x200 [r8723bs]
[  363.140092]        rtw_recv_entry+0x190/0x1120 [r8723bs]
[  363.140209]        rtl8723b_process_phy_info+0x3f9/0x750 [r8723bs]
[  363.140318]        tasklet_action_common.constprop.0+0xe8/0x110
[  363.140345]        __do_softirq+0xde/0x485
[  363.140372]        __irq_exit_rcu+0xd0/0x100
[  363.140393]        irq_exit_rcu+0xa/0x20
[  363.140413]        common_interrupt+0x83/0xa0
[  363.140440]        asm_common_interrupt+0x1e/0x40
[  363.140463]        finish_task_switch.isra.0+0x157/0x3d0
[  363.140492]        __schedule+0x447/0x1880
[  363.140516]        schedule+0x59/0xc0
[  363.140537]        smpboot_thread_fn+0x161/0x1c0
[  363.140565]        kthread+0x143/0x160
[  363.140585]        ret_from_fork+0x22/0x30
[  363.140614]
               -> #1 (&pmlmepriv->scanned_queue.lock){+.-.}-{2:2}:
[  363.140653]        _raw_spin_lock_bh+0x34/0x40
[  363.140675]        rtw_free_network_queue+0x31/0x80 [r8723bs]
[  363.140776]        rtw_sitesurvey_cmd+0x79/0x1e0 [r8723bs]
[  363.140869]        rtw_cfg80211_surveydone_event_callback+0x3cf/0x470 [r8723bs]
[  363.140973]        rdev_scan+0x42/0x1a0 [cfg80211]
[  363.141307]        nl80211_trigger_scan+0x566/0x660 [cfg80211]
[  363.141635]        genl_family_rcv_msg_doit+0xcd/0x110
[  363.141661]        genl_rcv_msg+0xce/0x1c0
[  363.141680]        netlink_rcv_skb+0x50/0xf0
[  363.141699]        genl_rcv+0x24/0x40
[  363.141717]        netlink_unicast+0x16d/0x230
[  363.141736]        netlink_sendmsg+0x22b/0x450
[  363.141755]        sock_sendmsg+0x5e/0x60
[  363.141781]        ____sys_sendmsg+0x22f/0x270
[  363.141803]        ___sys_sendmsg+0x81/0xc0
[  363.141828]        __sys_sendmsg+0x49/0x80
[  363.141851]        do_syscall_64+0x3b/0x90
[  363.141873]        entry_SYSCALL_64_after_hwframe+0x44/0xae
[  363.141895]
               -> #0 (&pmlmepriv->lock){+.-.}-{2:2}:
[  363.141930]        __lock_acquire+0x1158/0x1de0
[  363.141954]        lock_acquire+0xb5/0x2b0
[  363.141974]        _raw_spin_lock_bh+0x34/0x40
[  363.141993]        _rtw_join_timeout_handler+0x3c/0x160 [r8723bs]
[  363.142097]        call_timer_fn+0x94/0x260
[  363.142122]        __run_timers.part.0+0x1bf/0x290
[  363.142147]        run_timer_softirq+0x26/0x50
[  363.142171]        __do_softirq+0xde/0x485
[  363.142193]        __irq_exit_rcu+0xd0/0x100
[  363.142215]        irq_exit_rcu+0xa/0x20
[  363.142235]        sysvec_apic_timer_interrupt+0x72/0x90
[  363.142260]        asm_sysvec_apic_timer_interrupt+0x12/0x20
[  363.142283]        __module_address.part.0+0x0/0xd0
[  363.142309]        is_module_address+0x25/0x40
[  363.142334]        static_obj+0x4f/0x60
[  363.142361]        lockdep_init_map_type+0x47/0x220
[  363.142382]        __init_swait_queue_head+0x45/0x60
[  363.142408]        mmc_wait_for_req+0x4a/0xc0 [mmc_core]
[  363.142504]        mmc_wait_for_cmd+0x55/0x70 [mmc_core]
[  363.142592]        mmc_io_rw_direct+0x75/0xe0 [mmc_core]
[  363.142691]        sdio_writeb+0x2e/0x50 [mmc_core]
[  363.142788]        _sd_cmd52_write+0x62/0x80 [r8723bs]
[  363.142885]        sd_cmd52_write+0x6c/0xb0 [r8723bs]
[  363.142981]        rtl8723bs_set_hal_ops+0x982/0x9b0 [r8723bs]
[  363.143089]        rtw_write16+0x1e/0x30 [r8723bs]
[  363.143184]        SetHwReg8723B+0xcc9/0xd30 [r8723bs]
[  363.143294]        mlmeext_joinbss_event_callback+0x17a/0x1a0 [r8723bs]
[  363.143405]        rtw_joinbss_event_callback+0x11/0x20 [r8723bs]
[  363.143507]        mlme_evt_hdl+0x4d/0x70 [r8723bs]
[  363.143620]        rtw_cmd_thread+0x168/0x3c0 [r8723bs]
[  363.143712]        kthread+0x143/0x160
[  363.143732]        ret_from_fork+0x22/0x30
[  363.143757]
               other info that might help us debug this:

[  363.143768] Chain exists of:
                 &pmlmepriv->lock --> &pmlmepriv->scanned_queue.lock --> (&pmlmepriv->assoc_timer)

[  363.143809]  Possible unsafe locking scenario:

[  363.143819]        CPU0                    CPU1
[  363.143831]        ----                    ----
[  363.143841]   lock((&pmlmepriv->assoc_timer));
[  363.143862]                                lock(&pmlmepriv->scanned_queue.lock);
[  363.143882]                                lock((&pmlmepriv->assoc_timer));
[  363.143902]   lock(&pmlmepriv->lock);
[  363.143921]
                *** DEADLOCK ***

Make rtw_joinbss_event_prehandle() release the scanned_queue.lock before
it deletes the timer to avoid this (it is still holding pmlmepriv->lock
protecting against racing the timer).

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210920145502.155454-3-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Nov 24, 2021
[ Upstream commit a7ac783 ]

Lockdep complains about rtw_free_assoc_resources() taking the sta_hash_lock
followed by it calling rtw_free_stainfo() which takes xmitpriv->lock.
While the rtl8723bs_xmit_thread takes the sta_hash_lock while already
holding the xmitpriv->lock:

[  103.849756] ======================================================
[  103.849761] WARNING: possible circular locking dependency detected
[  103.849767] 5.15.0-rc1+ torvalds#470 Tainted: G         C  E
[  103.849773] ------------------------------------------------------
[  103.849776] wpa_supplicant/695 is trying to acquire lock:
[  103.849781] ffffa5d0c0562b00 (&pxmitpriv->lock){+.-.}-{2:2}, at: rtw_free_stainfo+0x8a/0x510 [r8723bs]
[  103.849840]
               but task is already holding lock:
[  103.849843] ffffa5d0c05636a8 (&pstapriv->sta_hash_lock){+.-.}-{2:2}, at: rtw_free_assoc_resources+0x48/0x110 [r8723bs]
[  103.849881]
               which lock already depends on the new lock.

[  103.849884]
               the existing dependency chain (in reverse order) is:
[  103.849887]
               -> #1 (&pstapriv->sta_hash_lock){+.-.}-{2:2}:
[  103.849898]        _raw_spin_lock_bh+0x34/0x40
[  103.849913]        rtw_get_stainfo+0x93/0x110 [r8723bs]
[  103.849948]        rtw_make_wlanhdr+0x14a/0x270 [r8723bs]
[  103.849983]        rtw_xmitframe_coalesce+0x5c/0x6c0 [r8723bs]
[  103.850019]        rtl8723bs_xmit_thread+0x4ac/0x620 [r8723bs]
[  103.850050]        kthread+0x143/0x160
[  103.850058]        ret_from_fork+0x22/0x30
[  103.850067]
               -> #0 (&pxmitpriv->lock){+.-.}-{2:2}:
[  103.850077]        __lock_acquire+0x1158/0x1de0
[  103.850084]        lock_acquire+0xb5/0x2b0
[  103.850090]        _raw_spin_lock_bh+0x34/0x40
[  103.850095]        rtw_free_stainfo+0x8a/0x510 [r8723bs]
[  103.850130]        rtw_free_assoc_resources+0x53/0x110 [r8723bs]
[  103.850159]        PHY_IQCalibrate_8723B+0x122b/0x36a0 [r8723bs]
[  103.850189]        cfg80211_disconnect+0x173/0x320 [cfg80211]
[  103.850331]        nl80211_disconnect+0x6e/0xb0 [cfg80211]
[  103.850422]        genl_family_rcv_msg_doit+0xcd/0x110
[  103.850430]        genl_rcv_msg+0xce/0x1c0
[  103.850435]        netlink_rcv_skb+0x50/0xf0
[  103.850441]        genl_rcv+0x24/0x40
[  103.850446]        netlink_unicast+0x16d/0x230
[  103.850452]        netlink_sendmsg+0x22b/0x450
[  103.850457]        sock_sendmsg+0x5e/0x60
[  103.850465]        ____sys_sendmsg+0x22f/0x270
[  103.850472]        ___sys_sendmsg+0x81/0xc0
[  103.850479]        __sys_sendmsg+0x49/0x80
[  103.850485]        do_syscall_64+0x3b/0x90
[  103.850493]        entry_SYSCALL_64_after_hwframe+0x44/0xae
[  103.850500]
               other info that might help us debug this:

[  103.850504]  Possible unsafe locking scenario:

[  103.850507]        CPU0                    CPU1
[  103.850510]        ----                    ----
[  103.850512]   lock(&pstapriv->sta_hash_lock);
[  103.850518]                                lock(&pxmitpriv->lock);
[  103.850524]                                lock(&pstapriv->sta_hash_lock);
[  103.850530]   lock(&pxmitpriv->lock);
[  103.850535]
                *** DEADLOCK ***

Push the taking of sta_hash_lock down into rtw_free_stainfo(),
where the critical section is, this allows taking the lock after
rtw_free_stainfo() has released pxmitpriv->lock.

This requires changing rtw_free_all_stainfo() so that it does its freeing
in 2 steps, first moving all stainfo-s to free to a local list while
holding the sta_hash_lock and then walking that list to call
rtw_free_stainfo() on them without holding the sta_hash_lock.

Pushing the taking of sta_hash_lock down into rtw_free_stainfo(),
also fixes a whole bunch of callers of rtw_free_stainfo() which
were not holding that lock even though they should.

Note that this also fixes the deadlock from the "remove possible
deadlock when disconnect" patch in a different way. But the
changes from that patch offer a nice locking cleanup regardless.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210920145502.155454-2-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Nov 24, 2021
[ Upstream commit bdc1bbd ]

The assoc_timer takes the pmlmepriv->lock and various functions which
take the pmlmepriv->scanned_queue.lock first take the pmlmepriv->lock,
this means that we cannot have code which waits for the timer
(timer_del_sync) while holding the pmlmepriv->scanned_queue.lock
to avoid a triangle deadlock:

[  363.139361] ======================================================
[  363.139377] WARNING: possible circular locking dependency detected
[  363.139396] 5.15.0-rc1+ torvalds#470 Tainted: G         C  E
[  363.139413] ------------------------------------------------------
[  363.139424] RTW_CMD_THREAD/2466 is trying to acquire lock:
[  363.139441] ffffbacd00699038 (&pmlmepriv->lock){+.-.}-{2:2}, at: _rtw_join_timeout_handler+0x3c/0x160 [r8723bs]
[  363.139598]
               but task is already holding lock:
[  363.139610] ffffbacd00128ea0 ((&pmlmepriv->assoc_timer)){+.-.}-{0:0}, at: call_timer_fn+0x5/0x260
[  363.139673]
               which lock already depends on the new lock.

[  363.139684]
               the existing dependency chain (in reverse order) is:
[  363.139696]
               -> #2 ((&pmlmepriv->assoc_timer)){+.-.}-{0:0}:
[  363.139734]        del_timer_sync+0x59/0x100
[  363.139762]        rtw_joinbss_event_prehandle+0x342/0x640 [r8723bs]
[  363.139870]        report_join_res+0xdf/0x110 [r8723bs]
[  363.139980]        OnAssocRsp+0x17a/0x200 [r8723bs]
[  363.140092]        rtw_recv_entry+0x190/0x1120 [r8723bs]
[  363.140209]        rtl8723b_process_phy_info+0x3f9/0x750 [r8723bs]
[  363.140318]        tasklet_action_common.constprop.0+0xe8/0x110
[  363.140345]        __do_softirq+0xde/0x485
[  363.140372]        __irq_exit_rcu+0xd0/0x100
[  363.140393]        irq_exit_rcu+0xa/0x20
[  363.140413]        common_interrupt+0x83/0xa0
[  363.140440]        asm_common_interrupt+0x1e/0x40
[  363.140463]        finish_task_switch.isra.0+0x157/0x3d0
[  363.140492]        __schedule+0x447/0x1880
[  363.140516]        schedule+0x59/0xc0
[  363.140537]        smpboot_thread_fn+0x161/0x1c0
[  363.140565]        kthread+0x143/0x160
[  363.140585]        ret_from_fork+0x22/0x30
[  363.140614]
               -> #1 (&pmlmepriv->scanned_queue.lock){+.-.}-{2:2}:
[  363.140653]        _raw_spin_lock_bh+0x34/0x40
[  363.140675]        rtw_free_network_queue+0x31/0x80 [r8723bs]
[  363.140776]        rtw_sitesurvey_cmd+0x79/0x1e0 [r8723bs]
[  363.140869]        rtw_cfg80211_surveydone_event_callback+0x3cf/0x470 [r8723bs]
[  363.140973]        rdev_scan+0x42/0x1a0 [cfg80211]
[  363.141307]        nl80211_trigger_scan+0x566/0x660 [cfg80211]
[  363.141635]        genl_family_rcv_msg_doit+0xcd/0x110
[  363.141661]        genl_rcv_msg+0xce/0x1c0
[  363.141680]        netlink_rcv_skb+0x50/0xf0
[  363.141699]        genl_rcv+0x24/0x40
[  363.141717]        netlink_unicast+0x16d/0x230
[  363.141736]        netlink_sendmsg+0x22b/0x450
[  363.141755]        sock_sendmsg+0x5e/0x60
[  363.141781]        ____sys_sendmsg+0x22f/0x270
[  363.141803]        ___sys_sendmsg+0x81/0xc0
[  363.141828]        __sys_sendmsg+0x49/0x80
[  363.141851]        do_syscall_64+0x3b/0x90
[  363.141873]        entry_SYSCALL_64_after_hwframe+0x44/0xae
[  363.141895]
               -> #0 (&pmlmepriv->lock){+.-.}-{2:2}:
[  363.141930]        __lock_acquire+0x1158/0x1de0
[  363.141954]        lock_acquire+0xb5/0x2b0
[  363.141974]        _raw_spin_lock_bh+0x34/0x40
[  363.141993]        _rtw_join_timeout_handler+0x3c/0x160 [r8723bs]
[  363.142097]        call_timer_fn+0x94/0x260
[  363.142122]        __run_timers.part.0+0x1bf/0x290
[  363.142147]        run_timer_softirq+0x26/0x50
[  363.142171]        __do_softirq+0xde/0x485
[  363.142193]        __irq_exit_rcu+0xd0/0x100
[  363.142215]        irq_exit_rcu+0xa/0x20
[  363.142235]        sysvec_apic_timer_interrupt+0x72/0x90
[  363.142260]        asm_sysvec_apic_timer_interrupt+0x12/0x20
[  363.142283]        __module_address.part.0+0x0/0xd0
[  363.142309]        is_module_address+0x25/0x40
[  363.142334]        static_obj+0x4f/0x60
[  363.142361]        lockdep_init_map_type+0x47/0x220
[  363.142382]        __init_swait_queue_head+0x45/0x60
[  363.142408]        mmc_wait_for_req+0x4a/0xc0 [mmc_core]
[  363.142504]        mmc_wait_for_cmd+0x55/0x70 [mmc_core]
[  363.142592]        mmc_io_rw_direct+0x75/0xe0 [mmc_core]
[  363.142691]        sdio_writeb+0x2e/0x50 [mmc_core]
[  363.142788]        _sd_cmd52_write+0x62/0x80 [r8723bs]
[  363.142885]        sd_cmd52_write+0x6c/0xb0 [r8723bs]
[  363.142981]        rtl8723bs_set_hal_ops+0x982/0x9b0 [r8723bs]
[  363.143089]        rtw_write16+0x1e/0x30 [r8723bs]
[  363.143184]        SetHwReg8723B+0xcc9/0xd30 [r8723bs]
[  363.143294]        mlmeext_joinbss_event_callback+0x17a/0x1a0 [r8723bs]
[  363.143405]        rtw_joinbss_event_callback+0x11/0x20 [r8723bs]
[  363.143507]        mlme_evt_hdl+0x4d/0x70 [r8723bs]
[  363.143620]        rtw_cmd_thread+0x168/0x3c0 [r8723bs]
[  363.143712]        kthread+0x143/0x160
[  363.143732]        ret_from_fork+0x22/0x30
[  363.143757]
               other info that might help us debug this:

[  363.143768] Chain exists of:
                 &pmlmepriv->lock --> &pmlmepriv->scanned_queue.lock --> (&pmlmepriv->assoc_timer)

[  363.143809]  Possible unsafe locking scenario:

[  363.143819]        CPU0                    CPU1
[  363.143831]        ----                    ----
[  363.143841]   lock((&pmlmepriv->assoc_timer));
[  363.143862]                                lock(&pmlmepriv->scanned_queue.lock);
[  363.143882]                                lock((&pmlmepriv->assoc_timer));
[  363.143902]   lock(&pmlmepriv->lock);
[  363.143921]
                *** DEADLOCK ***

Make rtw_joinbss_event_prehandle() release the scanned_queue.lock before
it deletes the timer to avoid this (it is still holding pmlmepriv->lock
protecting against racing the timer).

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210920145502.155454-3-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Nov 24, 2021
[ Upstream commit a7ac783 ]

Lockdep complains about rtw_free_assoc_resources() taking the sta_hash_lock
followed by it calling rtw_free_stainfo() which takes xmitpriv->lock.
While the rtl8723bs_xmit_thread takes the sta_hash_lock while already
holding the xmitpriv->lock:

[  103.849756] ======================================================
[  103.849761] WARNING: possible circular locking dependency detected
[  103.849767] 5.15.0-rc1+ torvalds#470 Tainted: G         C  E
[  103.849773] ------------------------------------------------------
[  103.849776] wpa_supplicant/695 is trying to acquire lock:
[  103.849781] ffffa5d0c0562b00 (&pxmitpriv->lock){+.-.}-{2:2}, at: rtw_free_stainfo+0x8a/0x510 [r8723bs]
[  103.849840]
               but task is already holding lock:
[  103.849843] ffffa5d0c05636a8 (&pstapriv->sta_hash_lock){+.-.}-{2:2}, at: rtw_free_assoc_resources+0x48/0x110 [r8723bs]
[  103.849881]
               which lock already depends on the new lock.

[  103.849884]
               the existing dependency chain (in reverse order) is:
[  103.849887]
               -> #1 (&pstapriv->sta_hash_lock){+.-.}-{2:2}:
[  103.849898]        _raw_spin_lock_bh+0x34/0x40
[  103.849913]        rtw_get_stainfo+0x93/0x110 [r8723bs]
[  103.849948]        rtw_make_wlanhdr+0x14a/0x270 [r8723bs]
[  103.849983]        rtw_xmitframe_coalesce+0x5c/0x6c0 [r8723bs]
[  103.850019]        rtl8723bs_xmit_thread+0x4ac/0x620 [r8723bs]
[  103.850050]        kthread+0x143/0x160
[  103.850058]        ret_from_fork+0x22/0x30
[  103.850067]
               -> #0 (&pxmitpriv->lock){+.-.}-{2:2}:
[  103.850077]        __lock_acquire+0x1158/0x1de0
[  103.850084]        lock_acquire+0xb5/0x2b0
[  103.850090]        _raw_spin_lock_bh+0x34/0x40
[  103.850095]        rtw_free_stainfo+0x8a/0x510 [r8723bs]
[  103.850130]        rtw_free_assoc_resources+0x53/0x110 [r8723bs]
[  103.850159]        PHY_IQCalibrate_8723B+0x122b/0x36a0 [r8723bs]
[  103.850189]        cfg80211_disconnect+0x173/0x320 [cfg80211]
[  103.850331]        nl80211_disconnect+0x6e/0xb0 [cfg80211]
[  103.850422]        genl_family_rcv_msg_doit+0xcd/0x110
[  103.850430]        genl_rcv_msg+0xce/0x1c0
[  103.850435]        netlink_rcv_skb+0x50/0xf0
[  103.850441]        genl_rcv+0x24/0x40
[  103.850446]        netlink_unicast+0x16d/0x230
[  103.850452]        netlink_sendmsg+0x22b/0x450
[  103.850457]        sock_sendmsg+0x5e/0x60
[  103.850465]        ____sys_sendmsg+0x22f/0x270
[  103.850472]        ___sys_sendmsg+0x81/0xc0
[  103.850479]        __sys_sendmsg+0x49/0x80
[  103.850485]        do_syscall_64+0x3b/0x90
[  103.850493]        entry_SYSCALL_64_after_hwframe+0x44/0xae
[  103.850500]
               other info that might help us debug this:

[  103.850504]  Possible unsafe locking scenario:

[  103.850507]        CPU0                    CPU1
[  103.850510]        ----                    ----
[  103.850512]   lock(&pstapriv->sta_hash_lock);
[  103.850518]                                lock(&pxmitpriv->lock);
[  103.850524]                                lock(&pstapriv->sta_hash_lock);
[  103.850530]   lock(&pxmitpriv->lock);
[  103.850535]
                *** DEADLOCK ***

Push the taking of sta_hash_lock down into rtw_free_stainfo(),
where the critical section is, this allows taking the lock after
rtw_free_stainfo() has released pxmitpriv->lock.

This requires changing rtw_free_all_stainfo() so that it does its freeing
in 2 steps, first moving all stainfo-s to free to a local list while
holding the sta_hash_lock and then walking that list to call
rtw_free_stainfo() on them without holding the sta_hash_lock.

Pushing the taking of sta_hash_lock down into rtw_free_stainfo(),
also fixes a whole bunch of callers of rtw_free_stainfo() which
were not holding that lock even though they should.

Note that this also fixes the deadlock from the "remove possible
deadlock when disconnect" patch in a different way. But the
changes from that patch offer a nice locking cleanup regardless.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210920145502.155454-2-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Nov 24, 2021
[ Upstream commit bdc1bbd ]

The assoc_timer takes the pmlmepriv->lock and various functions which
take the pmlmepriv->scanned_queue.lock first take the pmlmepriv->lock,
this means that we cannot have code which waits for the timer
(timer_del_sync) while holding the pmlmepriv->scanned_queue.lock
to avoid a triangle deadlock:

[  363.139361] ======================================================
[  363.139377] WARNING: possible circular locking dependency detected
[  363.139396] 5.15.0-rc1+ torvalds#470 Tainted: G         C  E
[  363.139413] ------------------------------------------------------
[  363.139424] RTW_CMD_THREAD/2466 is trying to acquire lock:
[  363.139441] ffffbacd00699038 (&pmlmepriv->lock){+.-.}-{2:2}, at: _rtw_join_timeout_handler+0x3c/0x160 [r8723bs]
[  363.139598]
               but task is already holding lock:
[  363.139610] ffffbacd00128ea0 ((&pmlmepriv->assoc_timer)){+.-.}-{0:0}, at: call_timer_fn+0x5/0x260
[  363.139673]
               which lock already depends on the new lock.

[  363.139684]
               the existing dependency chain (in reverse order) is:
[  363.139696]
               -> #2 ((&pmlmepriv->assoc_timer)){+.-.}-{0:0}:
[  363.139734]        del_timer_sync+0x59/0x100
[  363.139762]        rtw_joinbss_event_prehandle+0x342/0x640 [r8723bs]
[  363.139870]        report_join_res+0xdf/0x110 [r8723bs]
[  363.139980]        OnAssocRsp+0x17a/0x200 [r8723bs]
[  363.140092]        rtw_recv_entry+0x190/0x1120 [r8723bs]
[  363.140209]        rtl8723b_process_phy_info+0x3f9/0x750 [r8723bs]
[  363.140318]        tasklet_action_common.constprop.0+0xe8/0x110
[  363.140345]        __do_softirq+0xde/0x485
[  363.140372]        __irq_exit_rcu+0xd0/0x100
[  363.140393]        irq_exit_rcu+0xa/0x20
[  363.140413]        common_interrupt+0x83/0xa0
[  363.140440]        asm_common_interrupt+0x1e/0x40
[  363.140463]        finish_task_switch.isra.0+0x157/0x3d0
[  363.140492]        __schedule+0x447/0x1880
[  363.140516]        schedule+0x59/0xc0
[  363.140537]        smpboot_thread_fn+0x161/0x1c0
[  363.140565]        kthread+0x143/0x160
[  363.140585]        ret_from_fork+0x22/0x30
[  363.140614]
               -> #1 (&pmlmepriv->scanned_queue.lock){+.-.}-{2:2}:
[  363.140653]        _raw_spin_lock_bh+0x34/0x40
[  363.140675]        rtw_free_network_queue+0x31/0x80 [r8723bs]
[  363.140776]        rtw_sitesurvey_cmd+0x79/0x1e0 [r8723bs]
[  363.140869]        rtw_cfg80211_surveydone_event_callback+0x3cf/0x470 [r8723bs]
[  363.140973]        rdev_scan+0x42/0x1a0 [cfg80211]
[  363.141307]        nl80211_trigger_scan+0x566/0x660 [cfg80211]
[  363.141635]        genl_family_rcv_msg_doit+0xcd/0x110
[  363.141661]        genl_rcv_msg+0xce/0x1c0
[  363.141680]        netlink_rcv_skb+0x50/0xf0
[  363.141699]        genl_rcv+0x24/0x40
[  363.141717]        netlink_unicast+0x16d/0x230
[  363.141736]        netlink_sendmsg+0x22b/0x450
[  363.141755]        sock_sendmsg+0x5e/0x60
[  363.141781]        ____sys_sendmsg+0x22f/0x270
[  363.141803]        ___sys_sendmsg+0x81/0xc0
[  363.141828]        __sys_sendmsg+0x49/0x80
[  363.141851]        do_syscall_64+0x3b/0x90
[  363.141873]        entry_SYSCALL_64_after_hwframe+0x44/0xae
[  363.141895]
               -> #0 (&pmlmepriv->lock){+.-.}-{2:2}:
[  363.141930]        __lock_acquire+0x1158/0x1de0
[  363.141954]        lock_acquire+0xb5/0x2b0
[  363.141974]        _raw_spin_lock_bh+0x34/0x40
[  363.141993]        _rtw_join_timeout_handler+0x3c/0x160 [r8723bs]
[  363.142097]        call_timer_fn+0x94/0x260
[  363.142122]        __run_timers.part.0+0x1bf/0x290
[  363.142147]        run_timer_softirq+0x26/0x50
[  363.142171]        __do_softirq+0xde/0x485
[  363.142193]        __irq_exit_rcu+0xd0/0x100
[  363.142215]        irq_exit_rcu+0xa/0x20
[  363.142235]        sysvec_apic_timer_interrupt+0x72/0x90
[  363.142260]        asm_sysvec_apic_timer_interrupt+0x12/0x20
[  363.142283]        __module_address.part.0+0x0/0xd0
[  363.142309]        is_module_address+0x25/0x40
[  363.142334]        static_obj+0x4f/0x60
[  363.142361]        lockdep_init_map_type+0x47/0x220
[  363.142382]        __init_swait_queue_head+0x45/0x60
[  363.142408]        mmc_wait_for_req+0x4a/0xc0 [mmc_core]
[  363.142504]        mmc_wait_for_cmd+0x55/0x70 [mmc_core]
[  363.142592]        mmc_io_rw_direct+0x75/0xe0 [mmc_core]
[  363.142691]        sdio_writeb+0x2e/0x50 [mmc_core]
[  363.142788]        _sd_cmd52_write+0x62/0x80 [r8723bs]
[  363.142885]        sd_cmd52_write+0x6c/0xb0 [r8723bs]
[  363.142981]        rtl8723bs_set_hal_ops+0x982/0x9b0 [r8723bs]
[  363.143089]        rtw_write16+0x1e/0x30 [r8723bs]
[  363.143184]        SetHwReg8723B+0xcc9/0xd30 [r8723bs]
[  363.143294]        mlmeext_joinbss_event_callback+0x17a/0x1a0 [r8723bs]
[  363.143405]        rtw_joinbss_event_callback+0x11/0x20 [r8723bs]
[  363.143507]        mlme_evt_hdl+0x4d/0x70 [r8723bs]
[  363.143620]        rtw_cmd_thread+0x168/0x3c0 [r8723bs]
[  363.143712]        kthread+0x143/0x160
[  363.143732]        ret_from_fork+0x22/0x30
[  363.143757]
               other info that might help us debug this:

[  363.143768] Chain exists of:
                 &pmlmepriv->lock --> &pmlmepriv->scanned_queue.lock --> (&pmlmepriv->assoc_timer)

[  363.143809]  Possible unsafe locking scenario:

[  363.143819]        CPU0                    CPU1
[  363.143831]        ----                    ----
[  363.143841]   lock((&pmlmepriv->assoc_timer));
[  363.143862]                                lock(&pmlmepriv->scanned_queue.lock);
[  363.143882]                                lock((&pmlmepriv->assoc_timer));
[  363.143902]   lock(&pmlmepriv->lock);
[  363.143921]
                *** DEADLOCK ***

Make rtw_joinbss_event_prehandle() release the scanned_queue.lock before
it deletes the timer to avoid this (it is still holding pmlmepriv->lock
protecting against racing the timer).

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210920145502.155454-3-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Nov 24, 2021
[ Upstream commit a7ac783 ]

Lockdep complains about rtw_free_assoc_resources() taking the sta_hash_lock
followed by it calling rtw_free_stainfo() which takes xmitpriv->lock.
While the rtl8723bs_xmit_thread takes the sta_hash_lock while already
holding the xmitpriv->lock:

[  103.849756] ======================================================
[  103.849761] WARNING: possible circular locking dependency detected
[  103.849767] 5.15.0-rc1+ torvalds#470 Tainted: G         C  E
[  103.849773] ------------------------------------------------------
[  103.849776] wpa_supplicant/695 is trying to acquire lock:
[  103.849781] ffffa5d0c0562b00 (&pxmitpriv->lock){+.-.}-{2:2}, at: rtw_free_stainfo+0x8a/0x510 [r8723bs]
[  103.849840]
               but task is already holding lock:
[  103.849843] ffffa5d0c05636a8 (&pstapriv->sta_hash_lock){+.-.}-{2:2}, at: rtw_free_assoc_resources+0x48/0x110 [r8723bs]
[  103.849881]
               which lock already depends on the new lock.

[  103.849884]
               the existing dependency chain (in reverse order) is:
[  103.849887]
               -> #1 (&pstapriv->sta_hash_lock){+.-.}-{2:2}:
[  103.849898]        _raw_spin_lock_bh+0x34/0x40
[  103.849913]        rtw_get_stainfo+0x93/0x110 [r8723bs]
[  103.849948]        rtw_make_wlanhdr+0x14a/0x270 [r8723bs]
[  103.849983]        rtw_xmitframe_coalesce+0x5c/0x6c0 [r8723bs]
[  103.850019]        rtl8723bs_xmit_thread+0x4ac/0x620 [r8723bs]
[  103.850050]        kthread+0x143/0x160
[  103.850058]        ret_from_fork+0x22/0x30
[  103.850067]
               -> #0 (&pxmitpriv->lock){+.-.}-{2:2}:
[  103.850077]        __lock_acquire+0x1158/0x1de0
[  103.850084]        lock_acquire+0xb5/0x2b0
[  103.850090]        _raw_spin_lock_bh+0x34/0x40
[  103.850095]        rtw_free_stainfo+0x8a/0x510 [r8723bs]
[  103.850130]        rtw_free_assoc_resources+0x53/0x110 [r8723bs]
[  103.850159]        PHY_IQCalibrate_8723B+0x122b/0x36a0 [r8723bs]
[  103.850189]        cfg80211_disconnect+0x173/0x320 [cfg80211]
[  103.850331]        nl80211_disconnect+0x6e/0xb0 [cfg80211]
[  103.850422]        genl_family_rcv_msg_doit+0xcd/0x110
[  103.850430]        genl_rcv_msg+0xce/0x1c0
[  103.850435]        netlink_rcv_skb+0x50/0xf0
[  103.850441]        genl_rcv+0x24/0x40
[  103.850446]        netlink_unicast+0x16d/0x230
[  103.850452]        netlink_sendmsg+0x22b/0x450
[  103.850457]        sock_sendmsg+0x5e/0x60
[  103.850465]        ____sys_sendmsg+0x22f/0x270
[  103.850472]        ___sys_sendmsg+0x81/0xc0
[  103.850479]        __sys_sendmsg+0x49/0x80
[  103.850485]        do_syscall_64+0x3b/0x90
[  103.850493]        entry_SYSCALL_64_after_hwframe+0x44/0xae
[  103.850500]
               other info that might help us debug this:

[  103.850504]  Possible unsafe locking scenario:

[  103.850507]        CPU0                    CPU1
[  103.850510]        ----                    ----
[  103.850512]   lock(&pstapriv->sta_hash_lock);
[  103.850518]                                lock(&pxmitpriv->lock);
[  103.850524]                                lock(&pstapriv->sta_hash_lock);
[  103.850530]   lock(&pxmitpriv->lock);
[  103.850535]
                *** DEADLOCK ***

Push the taking of sta_hash_lock down into rtw_free_stainfo(),
where the critical section is, this allows taking the lock after
rtw_free_stainfo() has released pxmitpriv->lock.

This requires changing rtw_free_all_stainfo() so that it does its freeing
in 2 steps, first moving all stainfo-s to free to a local list while
holding the sta_hash_lock and then walking that list to call
rtw_free_stainfo() on them without holding the sta_hash_lock.

Pushing the taking of sta_hash_lock down into rtw_free_stainfo(),
also fixes a whole bunch of callers of rtw_free_stainfo() which
were not holding that lock even though they should.

Note that this also fixes the deadlock from the "remove possible
deadlock when disconnect" patch in a different way. But the
changes from that patch offer a nice locking cleanup regardless.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210920145502.155454-2-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Nov 24, 2021
[ Upstream commit bdc1bbd ]

The assoc_timer takes the pmlmepriv->lock and various functions which
take the pmlmepriv->scanned_queue.lock first take the pmlmepriv->lock,
this means that we cannot have code which waits for the timer
(timer_del_sync) while holding the pmlmepriv->scanned_queue.lock
to avoid a triangle deadlock:

[  363.139361] ======================================================
[  363.139377] WARNING: possible circular locking dependency detected
[  363.139396] 5.15.0-rc1+ torvalds#470 Tainted: G         C  E
[  363.139413] ------------------------------------------------------
[  363.139424] RTW_CMD_THREAD/2466 is trying to acquire lock:
[  363.139441] ffffbacd00699038 (&pmlmepriv->lock){+.-.}-{2:2}, at: _rtw_join_timeout_handler+0x3c/0x160 [r8723bs]
[  363.139598]
               but task is already holding lock:
[  363.139610] ffffbacd00128ea0 ((&pmlmepriv->assoc_timer)){+.-.}-{0:0}, at: call_timer_fn+0x5/0x260
[  363.139673]
               which lock already depends on the new lock.

[  363.139684]
               the existing dependency chain (in reverse order) is:
[  363.139696]
               -> #2 ((&pmlmepriv->assoc_timer)){+.-.}-{0:0}:
[  363.139734]        del_timer_sync+0x59/0x100
[  363.139762]        rtw_joinbss_event_prehandle+0x342/0x640 [r8723bs]
[  363.139870]        report_join_res+0xdf/0x110 [r8723bs]
[  363.139980]        OnAssocRsp+0x17a/0x200 [r8723bs]
[  363.140092]        rtw_recv_entry+0x190/0x1120 [r8723bs]
[  363.140209]        rtl8723b_process_phy_info+0x3f9/0x750 [r8723bs]
[  363.140318]        tasklet_action_common.constprop.0+0xe8/0x110
[  363.140345]        __do_softirq+0xde/0x485
[  363.140372]        __irq_exit_rcu+0xd0/0x100
[  363.140393]        irq_exit_rcu+0xa/0x20
[  363.140413]        common_interrupt+0x83/0xa0
[  363.140440]        asm_common_interrupt+0x1e/0x40
[  363.140463]        finish_task_switch.isra.0+0x157/0x3d0
[  363.140492]        __schedule+0x447/0x1880
[  363.140516]        schedule+0x59/0xc0
[  363.140537]        smpboot_thread_fn+0x161/0x1c0
[  363.140565]        kthread+0x143/0x160
[  363.140585]        ret_from_fork+0x22/0x30
[  363.140614]
               -> #1 (&pmlmepriv->scanned_queue.lock){+.-.}-{2:2}:
[  363.140653]        _raw_spin_lock_bh+0x34/0x40
[  363.140675]        rtw_free_network_queue+0x31/0x80 [r8723bs]
[  363.140776]        rtw_sitesurvey_cmd+0x79/0x1e0 [r8723bs]
[  363.140869]        rtw_cfg80211_surveydone_event_callback+0x3cf/0x470 [r8723bs]
[  363.140973]        rdev_scan+0x42/0x1a0 [cfg80211]
[  363.141307]        nl80211_trigger_scan+0x566/0x660 [cfg80211]
[  363.141635]        genl_family_rcv_msg_doit+0xcd/0x110
[  363.141661]        genl_rcv_msg+0xce/0x1c0
[  363.141680]        netlink_rcv_skb+0x50/0xf0
[  363.141699]        genl_rcv+0x24/0x40
[  363.141717]        netlink_unicast+0x16d/0x230
[  363.141736]        netlink_sendmsg+0x22b/0x450
[  363.141755]        sock_sendmsg+0x5e/0x60
[  363.141781]        ____sys_sendmsg+0x22f/0x270
[  363.141803]        ___sys_sendmsg+0x81/0xc0
[  363.141828]        __sys_sendmsg+0x49/0x80
[  363.141851]        do_syscall_64+0x3b/0x90
[  363.141873]        entry_SYSCALL_64_after_hwframe+0x44/0xae
[  363.141895]
               -> #0 (&pmlmepriv->lock){+.-.}-{2:2}:
[  363.141930]        __lock_acquire+0x1158/0x1de0
[  363.141954]        lock_acquire+0xb5/0x2b0
[  363.141974]        _raw_spin_lock_bh+0x34/0x40
[  363.141993]        _rtw_join_timeout_handler+0x3c/0x160 [r8723bs]
[  363.142097]        call_timer_fn+0x94/0x260
[  363.142122]        __run_timers.part.0+0x1bf/0x290
[  363.142147]        run_timer_softirq+0x26/0x50
[  363.142171]        __do_softirq+0xde/0x485
[  363.142193]        __irq_exit_rcu+0xd0/0x100
[  363.142215]        irq_exit_rcu+0xa/0x20
[  363.142235]        sysvec_apic_timer_interrupt+0x72/0x90
[  363.142260]        asm_sysvec_apic_timer_interrupt+0x12/0x20
[  363.142283]        __module_address.part.0+0x0/0xd0
[  363.142309]        is_module_address+0x25/0x40
[  363.142334]        static_obj+0x4f/0x60
[  363.142361]        lockdep_init_map_type+0x47/0x220
[  363.142382]        __init_swait_queue_head+0x45/0x60
[  363.142408]        mmc_wait_for_req+0x4a/0xc0 [mmc_core]
[  363.142504]        mmc_wait_for_cmd+0x55/0x70 [mmc_core]
[  363.142592]        mmc_io_rw_direct+0x75/0xe0 [mmc_core]
[  363.142691]        sdio_writeb+0x2e/0x50 [mmc_core]
[  363.142788]        _sd_cmd52_write+0x62/0x80 [r8723bs]
[  363.142885]        sd_cmd52_write+0x6c/0xb0 [r8723bs]
[  363.142981]        rtl8723bs_set_hal_ops+0x982/0x9b0 [r8723bs]
[  363.143089]        rtw_write16+0x1e/0x30 [r8723bs]
[  363.143184]        SetHwReg8723B+0xcc9/0xd30 [r8723bs]
[  363.143294]        mlmeext_joinbss_event_callback+0x17a/0x1a0 [r8723bs]
[  363.143405]        rtw_joinbss_event_callback+0x11/0x20 [r8723bs]
[  363.143507]        mlme_evt_hdl+0x4d/0x70 [r8723bs]
[  363.143620]        rtw_cmd_thread+0x168/0x3c0 [r8723bs]
[  363.143712]        kthread+0x143/0x160
[  363.143732]        ret_from_fork+0x22/0x30
[  363.143757]
               other info that might help us debug this:

[  363.143768] Chain exists of:
                 &pmlmepriv->lock --> &pmlmepriv->scanned_queue.lock --> (&pmlmepriv->assoc_timer)

[  363.143809]  Possible unsafe locking scenario:

[  363.143819]        CPU0                    CPU1
[  363.143831]        ----                    ----
[  363.143841]   lock((&pmlmepriv->assoc_timer));
[  363.143862]                                lock(&pmlmepriv->scanned_queue.lock);
[  363.143882]                                lock((&pmlmepriv->assoc_timer));
[  363.143902]   lock(&pmlmepriv->lock);
[  363.143921]
                *** DEADLOCK ***

Make rtw_joinbss_event_prehandle() release the scanned_queue.lock before
it deletes the timer to avoid this (it is still holding pmlmepriv->lock
protecting against racing the timer).

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210920145502.155454-3-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Nov 24, 2021
[ Upstream commit a7ac783 ]

Lockdep complains about rtw_free_assoc_resources() taking the sta_hash_lock
followed by it calling rtw_free_stainfo() which takes xmitpriv->lock.
While the rtl8723bs_xmit_thread takes the sta_hash_lock while already
holding the xmitpriv->lock:

[  103.849756] ======================================================
[  103.849761] WARNING: possible circular locking dependency detected
[  103.849767] 5.15.0-rc1+ torvalds#470 Tainted: G         C  E
[  103.849773] ------------------------------------------------------
[  103.849776] wpa_supplicant/695 is trying to acquire lock:
[  103.849781] ffffa5d0c0562b00 (&pxmitpriv->lock){+.-.}-{2:2}, at: rtw_free_stainfo+0x8a/0x510 [r8723bs]
[  103.849840]
               but task is already holding lock:
[  103.849843] ffffa5d0c05636a8 (&pstapriv->sta_hash_lock){+.-.}-{2:2}, at: rtw_free_assoc_resources+0x48/0x110 [r8723bs]
[  103.849881]
               which lock already depends on the new lock.

[  103.849884]
               the existing dependency chain (in reverse order) is:
[  103.849887]
               -> #1 (&pstapriv->sta_hash_lock){+.-.}-{2:2}:
[  103.849898]        _raw_spin_lock_bh+0x34/0x40
[  103.849913]        rtw_get_stainfo+0x93/0x110 [r8723bs]
[  103.849948]        rtw_make_wlanhdr+0x14a/0x270 [r8723bs]
[  103.849983]        rtw_xmitframe_coalesce+0x5c/0x6c0 [r8723bs]
[  103.850019]        rtl8723bs_xmit_thread+0x4ac/0x620 [r8723bs]
[  103.850050]        kthread+0x143/0x160
[  103.850058]        ret_from_fork+0x22/0x30
[  103.850067]
               -> #0 (&pxmitpriv->lock){+.-.}-{2:2}:
[  103.850077]        __lock_acquire+0x1158/0x1de0
[  103.850084]        lock_acquire+0xb5/0x2b0
[  103.850090]        _raw_spin_lock_bh+0x34/0x40
[  103.850095]        rtw_free_stainfo+0x8a/0x510 [r8723bs]
[  103.850130]        rtw_free_assoc_resources+0x53/0x110 [r8723bs]
[  103.850159]        PHY_IQCalibrate_8723B+0x122b/0x36a0 [r8723bs]
[  103.850189]        cfg80211_disconnect+0x173/0x320 [cfg80211]
[  103.850331]        nl80211_disconnect+0x6e/0xb0 [cfg80211]
[  103.850422]        genl_family_rcv_msg_doit+0xcd/0x110
[  103.850430]        genl_rcv_msg+0xce/0x1c0
[  103.850435]        netlink_rcv_skb+0x50/0xf0
[  103.850441]        genl_rcv+0x24/0x40
[  103.850446]        netlink_unicast+0x16d/0x230
[  103.850452]        netlink_sendmsg+0x22b/0x450
[  103.850457]        sock_sendmsg+0x5e/0x60
[  103.850465]        ____sys_sendmsg+0x22f/0x270
[  103.850472]        ___sys_sendmsg+0x81/0xc0
[  103.850479]        __sys_sendmsg+0x49/0x80
[  103.850485]        do_syscall_64+0x3b/0x90
[  103.850493]        entry_SYSCALL_64_after_hwframe+0x44/0xae
[  103.850500]
               other info that might help us debug this:

[  103.850504]  Possible unsafe locking scenario:

[  103.850507]        CPU0                    CPU1
[  103.850510]        ----                    ----
[  103.850512]   lock(&pstapriv->sta_hash_lock);
[  103.850518]                                lock(&pxmitpriv->lock);
[  103.850524]                                lock(&pstapriv->sta_hash_lock);
[  103.850530]   lock(&pxmitpriv->lock);
[  103.850535]
                *** DEADLOCK ***

Push the taking of sta_hash_lock down into rtw_free_stainfo(),
where the critical section is, this allows taking the lock after
rtw_free_stainfo() has released pxmitpriv->lock.

This requires changing rtw_free_all_stainfo() so that it does its freeing
in 2 steps, first moving all stainfo-s to free to a local list while
holding the sta_hash_lock and then walking that list to call
rtw_free_stainfo() on them without holding the sta_hash_lock.

Pushing the taking of sta_hash_lock down into rtw_free_stainfo(),
also fixes a whole bunch of callers of rtw_free_stainfo() which
were not holding that lock even though they should.

Note that this also fixes the deadlock from the "remove possible
deadlock when disconnect" patch in a different way. But the
changes from that patch offer a nice locking cleanup regardless.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210920145502.155454-2-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Nov 24, 2021
[ Upstream commit bdc1bbd ]

The assoc_timer takes the pmlmepriv->lock and various functions which
take the pmlmepriv->scanned_queue.lock first take the pmlmepriv->lock,
this means that we cannot have code which waits for the timer
(timer_del_sync) while holding the pmlmepriv->scanned_queue.lock
to avoid a triangle deadlock:

[  363.139361] ======================================================
[  363.139377] WARNING: possible circular locking dependency detected
[  363.139396] 5.15.0-rc1+ torvalds#470 Tainted: G         C  E
[  363.139413] ------------------------------------------------------
[  363.139424] RTW_CMD_THREAD/2466 is trying to acquire lock:
[  363.139441] ffffbacd00699038 (&pmlmepriv->lock){+.-.}-{2:2}, at: _rtw_join_timeout_handler+0x3c/0x160 [r8723bs]
[  363.139598]
               but task is already holding lock:
[  363.139610] ffffbacd00128ea0 ((&pmlmepriv->assoc_timer)){+.-.}-{0:0}, at: call_timer_fn+0x5/0x260
[  363.139673]
               which lock already depends on the new lock.

[  363.139684]
               the existing dependency chain (in reverse order) is:
[  363.139696]
               -> #2 ((&pmlmepriv->assoc_timer)){+.-.}-{0:0}:
[  363.139734]        del_timer_sync+0x59/0x100
[  363.139762]        rtw_joinbss_event_prehandle+0x342/0x640 [r8723bs]
[  363.139870]        report_join_res+0xdf/0x110 [r8723bs]
[  363.139980]        OnAssocRsp+0x17a/0x200 [r8723bs]
[  363.140092]        rtw_recv_entry+0x190/0x1120 [r8723bs]
[  363.140209]        rtl8723b_process_phy_info+0x3f9/0x750 [r8723bs]
[  363.140318]        tasklet_action_common.constprop.0+0xe8/0x110
[  363.140345]        __do_softirq+0xde/0x485
[  363.140372]        __irq_exit_rcu+0xd0/0x100
[  363.140393]        irq_exit_rcu+0xa/0x20
[  363.140413]        common_interrupt+0x83/0xa0
[  363.140440]        asm_common_interrupt+0x1e/0x40
[  363.140463]        finish_task_switch.isra.0+0x157/0x3d0
[  363.140492]        __schedule+0x447/0x1880
[  363.140516]        schedule+0x59/0xc0
[  363.140537]        smpboot_thread_fn+0x161/0x1c0
[  363.140565]        kthread+0x143/0x160
[  363.140585]        ret_from_fork+0x22/0x30
[  363.140614]
               -> #1 (&pmlmepriv->scanned_queue.lock){+.-.}-{2:2}:
[  363.140653]        _raw_spin_lock_bh+0x34/0x40
[  363.140675]        rtw_free_network_queue+0x31/0x80 [r8723bs]
[  363.140776]        rtw_sitesurvey_cmd+0x79/0x1e0 [r8723bs]
[  363.140869]        rtw_cfg80211_surveydone_event_callback+0x3cf/0x470 [r8723bs]
[  363.140973]        rdev_scan+0x42/0x1a0 [cfg80211]
[  363.141307]        nl80211_trigger_scan+0x566/0x660 [cfg80211]
[  363.141635]        genl_family_rcv_msg_doit+0xcd/0x110
[  363.141661]        genl_rcv_msg+0xce/0x1c0
[  363.141680]        netlink_rcv_skb+0x50/0xf0
[  363.141699]        genl_rcv+0x24/0x40
[  363.141717]        netlink_unicast+0x16d/0x230
[  363.141736]        netlink_sendmsg+0x22b/0x450
[  363.141755]        sock_sendmsg+0x5e/0x60
[  363.141781]        ____sys_sendmsg+0x22f/0x270
[  363.141803]        ___sys_sendmsg+0x81/0xc0
[  363.141828]        __sys_sendmsg+0x49/0x80
[  363.141851]        do_syscall_64+0x3b/0x90
[  363.141873]        entry_SYSCALL_64_after_hwframe+0x44/0xae
[  363.141895]
               -> #0 (&pmlmepriv->lock){+.-.}-{2:2}:
[  363.141930]        __lock_acquire+0x1158/0x1de0
[  363.141954]        lock_acquire+0xb5/0x2b0
[  363.141974]        _raw_spin_lock_bh+0x34/0x40
[  363.141993]        _rtw_join_timeout_handler+0x3c/0x160 [r8723bs]
[  363.142097]        call_timer_fn+0x94/0x260
[  363.142122]        __run_timers.part.0+0x1bf/0x290
[  363.142147]        run_timer_softirq+0x26/0x50
[  363.142171]        __do_softirq+0xde/0x485
[  363.142193]        __irq_exit_rcu+0xd0/0x100
[  363.142215]        irq_exit_rcu+0xa/0x20
[  363.142235]        sysvec_apic_timer_interrupt+0x72/0x90
[  363.142260]        asm_sysvec_apic_timer_interrupt+0x12/0x20
[  363.142283]        __module_address.part.0+0x0/0xd0
[  363.142309]        is_module_address+0x25/0x40
[  363.142334]        static_obj+0x4f/0x60
[  363.142361]        lockdep_init_map_type+0x47/0x220
[  363.142382]        __init_swait_queue_head+0x45/0x60
[  363.142408]        mmc_wait_for_req+0x4a/0xc0 [mmc_core]
[  363.142504]        mmc_wait_for_cmd+0x55/0x70 [mmc_core]
[  363.142592]        mmc_io_rw_direct+0x75/0xe0 [mmc_core]
[  363.142691]        sdio_writeb+0x2e/0x50 [mmc_core]
[  363.142788]        _sd_cmd52_write+0x62/0x80 [r8723bs]
[  363.142885]        sd_cmd52_write+0x6c/0xb0 [r8723bs]
[  363.142981]        rtl8723bs_set_hal_ops+0x982/0x9b0 [r8723bs]
[  363.143089]        rtw_write16+0x1e/0x30 [r8723bs]
[  363.143184]        SetHwReg8723B+0xcc9/0xd30 [r8723bs]
[  363.143294]        mlmeext_joinbss_event_callback+0x17a/0x1a0 [r8723bs]
[  363.143405]        rtw_joinbss_event_callback+0x11/0x20 [r8723bs]
[  363.143507]        mlme_evt_hdl+0x4d/0x70 [r8723bs]
[  363.143620]        rtw_cmd_thread+0x168/0x3c0 [r8723bs]
[  363.143712]        kthread+0x143/0x160
[  363.143732]        ret_from_fork+0x22/0x30
[  363.143757]
               other info that might help us debug this:

[  363.143768] Chain exists of:
                 &pmlmepriv->lock --> &pmlmepriv->scanned_queue.lock --> (&pmlmepriv->assoc_timer)

[  363.143809]  Possible unsafe locking scenario:

[  363.143819]        CPU0                    CPU1
[  363.143831]        ----                    ----
[  363.143841]   lock((&pmlmepriv->assoc_timer));
[  363.143862]                                lock(&pmlmepriv->scanned_queue.lock);
[  363.143882]                                lock((&pmlmepriv->assoc_timer));
[  363.143902]   lock(&pmlmepriv->lock);
[  363.143921]
                *** DEADLOCK ***

Make rtw_joinbss_event_prehandle() release the scanned_queue.lock before
it deletes the timer to avoid this (it is still holding pmlmepriv->lock
protecting against racing the timer).

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210920145502.155454-3-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Nov 24, 2021
[ Upstream commit a7ac783 ]

Lockdep complains about rtw_free_assoc_resources() taking the sta_hash_lock
followed by it calling rtw_free_stainfo() which takes xmitpriv->lock.
While the rtl8723bs_xmit_thread takes the sta_hash_lock while already
holding the xmitpriv->lock:

[  103.849756] ======================================================
[  103.849761] WARNING: possible circular locking dependency detected
[  103.849767] 5.15.0-rc1+ torvalds#470 Tainted: G         C  E
[  103.849773] ------------------------------------------------------
[  103.849776] wpa_supplicant/695 is trying to acquire lock:
[  103.849781] ffffa5d0c0562b00 (&pxmitpriv->lock){+.-.}-{2:2}, at: rtw_free_stainfo+0x8a/0x510 [r8723bs]
[  103.849840]
               but task is already holding lock:
[  103.849843] ffffa5d0c05636a8 (&pstapriv->sta_hash_lock){+.-.}-{2:2}, at: rtw_free_assoc_resources+0x48/0x110 [r8723bs]
[  103.849881]
               which lock already depends on the new lock.

[  103.849884]
               the existing dependency chain (in reverse order) is:
[  103.849887]
               -> #1 (&pstapriv->sta_hash_lock){+.-.}-{2:2}:
[  103.849898]        _raw_spin_lock_bh+0x34/0x40
[  103.849913]        rtw_get_stainfo+0x93/0x110 [r8723bs]
[  103.849948]        rtw_make_wlanhdr+0x14a/0x270 [r8723bs]
[  103.849983]        rtw_xmitframe_coalesce+0x5c/0x6c0 [r8723bs]
[  103.850019]        rtl8723bs_xmit_thread+0x4ac/0x620 [r8723bs]
[  103.850050]        kthread+0x143/0x160
[  103.850058]        ret_from_fork+0x22/0x30
[  103.850067]
               -> #0 (&pxmitpriv->lock){+.-.}-{2:2}:
[  103.850077]        __lock_acquire+0x1158/0x1de0
[  103.850084]        lock_acquire+0xb5/0x2b0
[  103.850090]        _raw_spin_lock_bh+0x34/0x40
[  103.850095]        rtw_free_stainfo+0x8a/0x510 [r8723bs]
[  103.850130]        rtw_free_assoc_resources+0x53/0x110 [r8723bs]
[  103.850159]        PHY_IQCalibrate_8723B+0x122b/0x36a0 [r8723bs]
[  103.850189]        cfg80211_disconnect+0x173/0x320 [cfg80211]
[  103.850331]        nl80211_disconnect+0x6e/0xb0 [cfg80211]
[  103.850422]        genl_family_rcv_msg_doit+0xcd/0x110
[  103.850430]        genl_rcv_msg+0xce/0x1c0
[  103.850435]        netlink_rcv_skb+0x50/0xf0
[  103.850441]        genl_rcv+0x24/0x40
[  103.850446]        netlink_unicast+0x16d/0x230
[  103.850452]        netlink_sendmsg+0x22b/0x450
[  103.850457]        sock_sendmsg+0x5e/0x60
[  103.850465]        ____sys_sendmsg+0x22f/0x270
[  103.850472]        ___sys_sendmsg+0x81/0xc0
[  103.850479]        __sys_sendmsg+0x49/0x80
[  103.850485]        do_syscall_64+0x3b/0x90
[  103.850493]        entry_SYSCALL_64_after_hwframe+0x44/0xae
[  103.850500]
               other info that might help us debug this:

[  103.850504]  Possible unsafe locking scenario:

[  103.850507]        CPU0                    CPU1
[  103.850510]        ----                    ----
[  103.850512]   lock(&pstapriv->sta_hash_lock);
[  103.850518]                                lock(&pxmitpriv->lock);
[  103.850524]                                lock(&pstapriv->sta_hash_lock);
[  103.850530]   lock(&pxmitpriv->lock);
[  103.850535]
                *** DEADLOCK ***

Push the taking of sta_hash_lock down into rtw_free_stainfo(),
where the critical section is, this allows taking the lock after
rtw_free_stainfo() has released pxmitpriv->lock.

This requires changing rtw_free_all_stainfo() so that it does its freeing
in 2 steps, first moving all stainfo-s to free to a local list while
holding the sta_hash_lock and then walking that list to call
rtw_free_stainfo() on them without holding the sta_hash_lock.

Pushing the taking of sta_hash_lock down into rtw_free_stainfo(),
also fixes a whole bunch of callers of rtw_free_stainfo() which
were not holding that lock even though they should.

Note that this also fixes the deadlock from the "remove possible
deadlock when disconnect" patch in a different way. But the
changes from that patch offer a nice locking cleanup regardless.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210920145502.155454-2-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Nov 24, 2021
[ Upstream commit bdc1bbd ]

The assoc_timer takes the pmlmepriv->lock and various functions which
take the pmlmepriv->scanned_queue.lock first take the pmlmepriv->lock,
this means that we cannot have code which waits for the timer
(timer_del_sync) while holding the pmlmepriv->scanned_queue.lock
to avoid a triangle deadlock:

[  363.139361] ======================================================
[  363.139377] WARNING: possible circular locking dependency detected
[  363.139396] 5.15.0-rc1+ torvalds#470 Tainted: G         C  E
[  363.139413] ------------------------------------------------------
[  363.139424] RTW_CMD_THREAD/2466 is trying to acquire lock:
[  363.139441] ffffbacd00699038 (&pmlmepriv->lock){+.-.}-{2:2}, at: _rtw_join_timeout_handler+0x3c/0x160 [r8723bs]
[  363.139598]
               but task is already holding lock:
[  363.139610] ffffbacd00128ea0 ((&pmlmepriv->assoc_timer)){+.-.}-{0:0}, at: call_timer_fn+0x5/0x260
[  363.139673]
               which lock already depends on the new lock.

[  363.139684]
               the existing dependency chain (in reverse order) is:
[  363.139696]
               -> #2 ((&pmlmepriv->assoc_timer)){+.-.}-{0:0}:
[  363.139734]        del_timer_sync+0x59/0x100
[  363.139762]        rtw_joinbss_event_prehandle+0x342/0x640 [r8723bs]
[  363.139870]        report_join_res+0xdf/0x110 [r8723bs]
[  363.139980]        OnAssocRsp+0x17a/0x200 [r8723bs]
[  363.140092]        rtw_recv_entry+0x190/0x1120 [r8723bs]
[  363.140209]        rtl8723b_process_phy_info+0x3f9/0x750 [r8723bs]
[  363.140318]        tasklet_action_common.constprop.0+0xe8/0x110
[  363.140345]        __do_softirq+0xde/0x485
[  363.140372]        __irq_exit_rcu+0xd0/0x100
[  363.140393]        irq_exit_rcu+0xa/0x20
[  363.140413]        common_interrupt+0x83/0xa0
[  363.140440]        asm_common_interrupt+0x1e/0x40
[  363.140463]        finish_task_switch.isra.0+0x157/0x3d0
[  363.140492]        __schedule+0x447/0x1880
[  363.140516]        schedule+0x59/0xc0
[  363.140537]        smpboot_thread_fn+0x161/0x1c0
[  363.140565]        kthread+0x143/0x160
[  363.140585]        ret_from_fork+0x22/0x30
[  363.140614]
               -> #1 (&pmlmepriv->scanned_queue.lock){+.-.}-{2:2}:
[  363.140653]        _raw_spin_lock_bh+0x34/0x40
[  363.140675]        rtw_free_network_queue+0x31/0x80 [r8723bs]
[  363.140776]        rtw_sitesurvey_cmd+0x79/0x1e0 [r8723bs]
[  363.140869]        rtw_cfg80211_surveydone_event_callback+0x3cf/0x470 [r8723bs]
[  363.140973]        rdev_scan+0x42/0x1a0 [cfg80211]
[  363.141307]        nl80211_trigger_scan+0x566/0x660 [cfg80211]
[  363.141635]        genl_family_rcv_msg_doit+0xcd/0x110
[  363.141661]        genl_rcv_msg+0xce/0x1c0
[  363.141680]        netlink_rcv_skb+0x50/0xf0
[  363.141699]        genl_rcv+0x24/0x40
[  363.141717]        netlink_unicast+0x16d/0x230
[  363.141736]        netlink_sendmsg+0x22b/0x450
[  363.141755]        sock_sendmsg+0x5e/0x60
[  363.141781]        ____sys_sendmsg+0x22f/0x270
[  363.141803]        ___sys_sendmsg+0x81/0xc0
[  363.141828]        __sys_sendmsg+0x49/0x80
[  363.141851]        do_syscall_64+0x3b/0x90
[  363.141873]        entry_SYSCALL_64_after_hwframe+0x44/0xae
[  363.141895]
               -> #0 (&pmlmepriv->lock){+.-.}-{2:2}:
[  363.141930]        __lock_acquire+0x1158/0x1de0
[  363.141954]        lock_acquire+0xb5/0x2b0
[  363.141974]        _raw_spin_lock_bh+0x34/0x40
[  363.141993]        _rtw_join_timeout_handler+0x3c/0x160 [r8723bs]
[  363.142097]        call_timer_fn+0x94/0x260
[  363.142122]        __run_timers.part.0+0x1bf/0x290
[  363.142147]        run_timer_softirq+0x26/0x50
[  363.142171]        __do_softirq+0xde/0x485
[  363.142193]        __irq_exit_rcu+0xd0/0x100
[  363.142215]        irq_exit_rcu+0xa/0x20
[  363.142235]        sysvec_apic_timer_interrupt+0x72/0x90
[  363.142260]        asm_sysvec_apic_timer_interrupt+0x12/0x20
[  363.142283]        __module_address.part.0+0x0/0xd0
[  363.142309]        is_module_address+0x25/0x40
[  363.142334]        static_obj+0x4f/0x60
[  363.142361]        lockdep_init_map_type+0x47/0x220
[  363.142382]        __init_swait_queue_head+0x45/0x60
[  363.142408]        mmc_wait_for_req+0x4a/0xc0 [mmc_core]
[  363.142504]        mmc_wait_for_cmd+0x55/0x70 [mmc_core]
[  363.142592]        mmc_io_rw_direct+0x75/0xe0 [mmc_core]
[  363.142691]        sdio_writeb+0x2e/0x50 [mmc_core]
[  363.142788]        _sd_cmd52_write+0x62/0x80 [r8723bs]
[  363.142885]        sd_cmd52_write+0x6c/0xb0 [r8723bs]
[  363.142981]        rtl8723bs_set_hal_ops+0x982/0x9b0 [r8723bs]
[  363.143089]        rtw_write16+0x1e/0x30 [r8723bs]
[  363.143184]        SetHwReg8723B+0xcc9/0xd30 [r8723bs]
[  363.143294]        mlmeext_joinbss_event_callback+0x17a/0x1a0 [r8723bs]
[  363.143405]        rtw_joinbss_event_callback+0x11/0x20 [r8723bs]
[  363.143507]        mlme_evt_hdl+0x4d/0x70 [r8723bs]
[  363.143620]        rtw_cmd_thread+0x168/0x3c0 [r8723bs]
[  363.143712]        kthread+0x143/0x160
[  363.143732]        ret_from_fork+0x22/0x30
[  363.143757]
               other info that might help us debug this:

[  363.143768] Chain exists of:
                 &pmlmepriv->lock --> &pmlmepriv->scanned_queue.lock --> (&pmlmepriv->assoc_timer)

[  363.143809]  Possible unsafe locking scenario:

[  363.143819]        CPU0                    CPU1
[  363.143831]        ----                    ----
[  363.143841]   lock((&pmlmepriv->assoc_timer));
[  363.143862]                                lock(&pmlmepriv->scanned_queue.lock);
[  363.143882]                                lock((&pmlmepriv->assoc_timer));
[  363.143902]   lock(&pmlmepriv->lock);
[  363.143921]
                *** DEADLOCK ***

Make rtw_joinbss_event_prehandle() release the scanned_queue.lock before
it deletes the timer to avoid this (it is still holding pmlmepriv->lock
protecting against racing the timer).

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210920145502.155454-3-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Nov 24, 2021
[ Upstream commit a7ac783 ]

Lockdep complains about rtw_free_assoc_resources() taking the sta_hash_lock
followed by it calling rtw_free_stainfo() which takes xmitpriv->lock.
While the rtl8723bs_xmit_thread takes the sta_hash_lock while already
holding the xmitpriv->lock:

[  103.849756] ======================================================
[  103.849761] WARNING: possible circular locking dependency detected
[  103.849767] 5.15.0-rc1+ torvalds#470 Tainted: G         C  E
[  103.849773] ------------------------------------------------------
[  103.849776] wpa_supplicant/695 is trying to acquire lock:
[  103.849781] ffffa5d0c0562b00 (&pxmitpriv->lock){+.-.}-{2:2}, at: rtw_free_stainfo+0x8a/0x510 [r8723bs]
[  103.849840]
               but task is already holding lock:
[  103.849843] ffffa5d0c05636a8 (&pstapriv->sta_hash_lock){+.-.}-{2:2}, at: rtw_free_assoc_resources+0x48/0x110 [r8723bs]
[  103.849881]
               which lock already depends on the new lock.

[  103.849884]
               the existing dependency chain (in reverse order) is:
[  103.849887]
               -> #1 (&pstapriv->sta_hash_lock){+.-.}-{2:2}:
[  103.849898]        _raw_spin_lock_bh+0x34/0x40
[  103.849913]        rtw_get_stainfo+0x93/0x110 [r8723bs]
[  103.849948]        rtw_make_wlanhdr+0x14a/0x270 [r8723bs]
[  103.849983]        rtw_xmitframe_coalesce+0x5c/0x6c0 [r8723bs]
[  103.850019]        rtl8723bs_xmit_thread+0x4ac/0x620 [r8723bs]
[  103.850050]        kthread+0x143/0x160
[  103.850058]        ret_from_fork+0x22/0x30
[  103.850067]
               -> #0 (&pxmitpriv->lock){+.-.}-{2:2}:
[  103.850077]        __lock_acquire+0x1158/0x1de0
[  103.850084]        lock_acquire+0xb5/0x2b0
[  103.850090]        _raw_spin_lock_bh+0x34/0x40
[  103.850095]        rtw_free_stainfo+0x8a/0x510 [r8723bs]
[  103.850130]        rtw_free_assoc_resources+0x53/0x110 [r8723bs]
[  103.850159]        PHY_IQCalibrate_8723B+0x122b/0x36a0 [r8723bs]
[  103.850189]        cfg80211_disconnect+0x173/0x320 [cfg80211]
[  103.850331]        nl80211_disconnect+0x6e/0xb0 [cfg80211]
[  103.850422]        genl_family_rcv_msg_doit+0xcd/0x110
[  103.850430]        genl_rcv_msg+0xce/0x1c0
[  103.850435]        netlink_rcv_skb+0x50/0xf0
[  103.850441]        genl_rcv+0x24/0x40
[  103.850446]        netlink_unicast+0x16d/0x230
[  103.850452]        netlink_sendmsg+0x22b/0x450
[  103.850457]        sock_sendmsg+0x5e/0x60
[  103.850465]        ____sys_sendmsg+0x22f/0x270
[  103.850472]        ___sys_sendmsg+0x81/0xc0
[  103.850479]        __sys_sendmsg+0x49/0x80
[  103.850485]        do_syscall_64+0x3b/0x90
[  103.850493]        entry_SYSCALL_64_after_hwframe+0x44/0xae
[  103.850500]
               other info that might help us debug this:

[  103.850504]  Possible unsafe locking scenario:

[  103.850507]        CPU0                    CPU1
[  103.850510]        ----                    ----
[  103.850512]   lock(&pstapriv->sta_hash_lock);
[  103.850518]                                lock(&pxmitpriv->lock);
[  103.850524]                                lock(&pstapriv->sta_hash_lock);
[  103.850530]   lock(&pxmitpriv->lock);
[  103.850535]
                *** DEADLOCK ***

Push the taking of sta_hash_lock down into rtw_free_stainfo(),
where the critical section is, this allows taking the lock after
rtw_free_stainfo() has released pxmitpriv->lock.

This requires changing rtw_free_all_stainfo() so that it does its freeing
in 2 steps, first moving all stainfo-s to free to a local list while
holding the sta_hash_lock and then walking that list to call
rtw_free_stainfo() on them without holding the sta_hash_lock.

Pushing the taking of sta_hash_lock down into rtw_free_stainfo(),
also fixes a whole bunch of callers of rtw_free_stainfo() which
were not holding that lock even though they should.

Note that this also fixes the deadlock from the "remove possible
deadlock when disconnect" patch in a different way. But the
changes from that patch offer a nice locking cleanup regardless.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210920145502.155454-2-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Nov 24, 2021
[ Upstream commit bdc1bbd ]

The assoc_timer takes the pmlmepriv->lock and various functions which
take the pmlmepriv->scanned_queue.lock first take the pmlmepriv->lock,
this means that we cannot have code which waits for the timer
(timer_del_sync) while holding the pmlmepriv->scanned_queue.lock
to avoid a triangle deadlock:

[  363.139361] ======================================================
[  363.139377] WARNING: possible circular locking dependency detected
[  363.139396] 5.15.0-rc1+ torvalds#470 Tainted: G         C  E
[  363.139413] ------------------------------------------------------
[  363.139424] RTW_CMD_THREAD/2466 is trying to acquire lock:
[  363.139441] ffffbacd00699038 (&pmlmepriv->lock){+.-.}-{2:2}, at: _rtw_join_timeout_handler+0x3c/0x160 [r8723bs]
[  363.139598]
               but task is already holding lock:
[  363.139610] ffffbacd00128ea0 ((&pmlmepriv->assoc_timer)){+.-.}-{0:0}, at: call_timer_fn+0x5/0x260
[  363.139673]
               which lock already depends on the new lock.

[  363.139684]
               the existing dependency chain (in reverse order) is:
[  363.139696]
               -> #2 ((&pmlmepriv->assoc_timer)){+.-.}-{0:0}:
[  363.139734]        del_timer_sync+0x59/0x100
[  363.139762]        rtw_joinbss_event_prehandle+0x342/0x640 [r8723bs]
[  363.139870]        report_join_res+0xdf/0x110 [r8723bs]
[  363.139980]        OnAssocRsp+0x17a/0x200 [r8723bs]
[  363.140092]        rtw_recv_entry+0x190/0x1120 [r8723bs]
[  363.140209]        rtl8723b_process_phy_info+0x3f9/0x750 [r8723bs]
[  363.140318]        tasklet_action_common.constprop.0+0xe8/0x110
[  363.140345]        __do_softirq+0xde/0x485
[  363.140372]        __irq_exit_rcu+0xd0/0x100
[  363.140393]        irq_exit_rcu+0xa/0x20
[  363.140413]        common_interrupt+0x83/0xa0
[  363.140440]        asm_common_interrupt+0x1e/0x40
[  363.140463]        finish_task_switch.isra.0+0x157/0x3d0
[  363.140492]        __schedule+0x447/0x1880
[  363.140516]        schedule+0x59/0xc0
[  363.140537]        smpboot_thread_fn+0x161/0x1c0
[  363.140565]        kthread+0x143/0x160
[  363.140585]        ret_from_fork+0x22/0x30
[  363.140614]
               -> #1 (&pmlmepriv->scanned_queue.lock){+.-.}-{2:2}:
[  363.140653]        _raw_spin_lock_bh+0x34/0x40
[  363.140675]        rtw_free_network_queue+0x31/0x80 [r8723bs]
[  363.140776]        rtw_sitesurvey_cmd+0x79/0x1e0 [r8723bs]
[  363.140869]        rtw_cfg80211_surveydone_event_callback+0x3cf/0x470 [r8723bs]
[  363.140973]        rdev_scan+0x42/0x1a0 [cfg80211]
[  363.141307]        nl80211_trigger_scan+0x566/0x660 [cfg80211]
[  363.141635]        genl_family_rcv_msg_doit+0xcd/0x110
[  363.141661]        genl_rcv_msg+0xce/0x1c0
[  363.141680]        netlink_rcv_skb+0x50/0xf0
[  363.141699]        genl_rcv+0x24/0x40
[  363.141717]        netlink_unicast+0x16d/0x230
[  363.141736]        netlink_sendmsg+0x22b/0x450
[  363.141755]        sock_sendmsg+0x5e/0x60
[  363.141781]        ____sys_sendmsg+0x22f/0x270
[  363.141803]        ___sys_sendmsg+0x81/0xc0
[  363.141828]        __sys_sendmsg+0x49/0x80
[  363.141851]        do_syscall_64+0x3b/0x90
[  363.141873]        entry_SYSCALL_64_after_hwframe+0x44/0xae
[  363.141895]
               -> #0 (&pmlmepriv->lock){+.-.}-{2:2}:
[  363.141930]        __lock_acquire+0x1158/0x1de0
[  363.141954]        lock_acquire+0xb5/0x2b0
[  363.141974]        _raw_spin_lock_bh+0x34/0x40
[  363.141993]        _rtw_join_timeout_handler+0x3c/0x160 [r8723bs]
[  363.142097]        call_timer_fn+0x94/0x260
[  363.142122]        __run_timers.part.0+0x1bf/0x290
[  363.142147]        run_timer_softirq+0x26/0x50
[  363.142171]        __do_softirq+0xde/0x485
[  363.142193]        __irq_exit_rcu+0xd0/0x100
[  363.142215]        irq_exit_rcu+0xa/0x20
[  363.142235]        sysvec_apic_timer_interrupt+0x72/0x90
[  363.142260]        asm_sysvec_apic_timer_interrupt+0x12/0x20
[  363.142283]        __module_address.part.0+0x0/0xd0
[  363.142309]        is_module_address+0x25/0x40
[  363.142334]        static_obj+0x4f/0x60
[  363.142361]        lockdep_init_map_type+0x47/0x220
[  363.142382]        __init_swait_queue_head+0x45/0x60
[  363.142408]        mmc_wait_for_req+0x4a/0xc0 [mmc_core]
[  363.142504]        mmc_wait_for_cmd+0x55/0x70 [mmc_core]
[  363.142592]        mmc_io_rw_direct+0x75/0xe0 [mmc_core]
[  363.142691]        sdio_writeb+0x2e/0x50 [mmc_core]
[  363.142788]        _sd_cmd52_write+0x62/0x80 [r8723bs]
[  363.142885]        sd_cmd52_write+0x6c/0xb0 [r8723bs]
[  363.142981]        rtl8723bs_set_hal_ops+0x982/0x9b0 [r8723bs]
[  363.143089]        rtw_write16+0x1e/0x30 [r8723bs]
[  363.143184]        SetHwReg8723B+0xcc9/0xd30 [r8723bs]
[  363.143294]        mlmeext_joinbss_event_callback+0x17a/0x1a0 [r8723bs]
[  363.143405]        rtw_joinbss_event_callback+0x11/0x20 [r8723bs]
[  363.143507]        mlme_evt_hdl+0x4d/0x70 [r8723bs]
[  363.143620]        rtw_cmd_thread+0x168/0x3c0 [r8723bs]
[  363.143712]        kthread+0x143/0x160
[  363.143732]        ret_from_fork+0x22/0x30
[  363.143757]
               other info that might help us debug this:

[  363.143768] Chain exists of:
                 &pmlmepriv->lock --> &pmlmepriv->scanned_queue.lock --> (&pmlmepriv->assoc_timer)

[  363.143809]  Possible unsafe locking scenario:

[  363.143819]        CPU0                    CPU1
[  363.143831]        ----                    ----
[  363.143841]   lock((&pmlmepriv->assoc_timer));
[  363.143862]                                lock(&pmlmepriv->scanned_queue.lock);
[  363.143882]                                lock((&pmlmepriv->assoc_timer));
[  363.143902]   lock(&pmlmepriv->lock);
[  363.143921]
                *** DEADLOCK ***

Make rtw_joinbss_event_prehandle() release the scanned_queue.lock before
it deletes the timer to avoid this (it is still holding pmlmepriv->lock
protecting against racing the timer).

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210920145502.155454-3-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Nov 24, 2021
[ Upstream commit a7ac783 ]

Lockdep complains about rtw_free_assoc_resources() taking the sta_hash_lock
followed by it calling rtw_free_stainfo() which takes xmitpriv->lock.
While the rtl8723bs_xmit_thread takes the sta_hash_lock while already
holding the xmitpriv->lock:

[  103.849756] ======================================================
[  103.849761] WARNING: possible circular locking dependency detected
[  103.849767] 5.15.0-rc1+ torvalds#470 Tainted: G         C  E
[  103.849773] ------------------------------------------------------
[  103.849776] wpa_supplicant/695 is trying to acquire lock:
[  103.849781] ffffa5d0c0562b00 (&pxmitpriv->lock){+.-.}-{2:2}, at: rtw_free_stainfo+0x8a/0x510 [r8723bs]
[  103.849840]
               but task is already holding lock:
[  103.849843] ffffa5d0c05636a8 (&pstapriv->sta_hash_lock){+.-.}-{2:2}, at: rtw_free_assoc_resources+0x48/0x110 [r8723bs]
[  103.849881]
               which lock already depends on the new lock.

[  103.849884]
               the existing dependency chain (in reverse order) is:
[  103.849887]
               -> #1 (&pstapriv->sta_hash_lock){+.-.}-{2:2}:
[  103.849898]        _raw_spin_lock_bh+0x34/0x40
[  103.849913]        rtw_get_stainfo+0x93/0x110 [r8723bs]
[  103.849948]        rtw_make_wlanhdr+0x14a/0x270 [r8723bs]
[  103.849983]        rtw_xmitframe_coalesce+0x5c/0x6c0 [r8723bs]
[  103.850019]        rtl8723bs_xmit_thread+0x4ac/0x620 [r8723bs]
[  103.850050]        kthread+0x143/0x160
[  103.850058]        ret_from_fork+0x22/0x30
[  103.850067]
               -> #0 (&pxmitpriv->lock){+.-.}-{2:2}:
[  103.850077]        __lock_acquire+0x1158/0x1de0
[  103.850084]        lock_acquire+0xb5/0x2b0
[  103.850090]        _raw_spin_lock_bh+0x34/0x40
[  103.850095]        rtw_free_stainfo+0x8a/0x510 [r8723bs]
[  103.850130]        rtw_free_assoc_resources+0x53/0x110 [r8723bs]
[  103.850159]        PHY_IQCalibrate_8723B+0x122b/0x36a0 [r8723bs]
[  103.850189]        cfg80211_disconnect+0x173/0x320 [cfg80211]
[  103.850331]        nl80211_disconnect+0x6e/0xb0 [cfg80211]
[  103.850422]        genl_family_rcv_msg_doit+0xcd/0x110
[  103.850430]        genl_rcv_msg+0xce/0x1c0
[  103.850435]        netlink_rcv_skb+0x50/0xf0
[  103.850441]        genl_rcv+0x24/0x40
[  103.850446]        netlink_unicast+0x16d/0x230
[  103.850452]        netlink_sendmsg+0x22b/0x450
[  103.850457]        sock_sendmsg+0x5e/0x60
[  103.850465]        ____sys_sendmsg+0x22f/0x270
[  103.850472]        ___sys_sendmsg+0x81/0xc0
[  103.850479]        __sys_sendmsg+0x49/0x80
[  103.850485]        do_syscall_64+0x3b/0x90
[  103.850493]        entry_SYSCALL_64_after_hwframe+0x44/0xae
[  103.850500]
               other info that might help us debug this:

[  103.850504]  Possible unsafe locking scenario:

[  103.850507]        CPU0                    CPU1
[  103.850510]        ----                    ----
[  103.850512]   lock(&pstapriv->sta_hash_lock);
[  103.850518]                                lock(&pxmitpriv->lock);
[  103.850524]                                lock(&pstapriv->sta_hash_lock);
[  103.850530]   lock(&pxmitpriv->lock);
[  103.850535]
                *** DEADLOCK ***

Push the taking of sta_hash_lock down into rtw_free_stainfo(),
where the critical section is, this allows taking the lock after
rtw_free_stainfo() has released pxmitpriv->lock.

This requires changing rtw_free_all_stainfo() so that it does its freeing
in 2 steps, first moving all stainfo-s to free to a local list while
holding the sta_hash_lock and then walking that list to call
rtw_free_stainfo() on them without holding the sta_hash_lock.

Pushing the taking of sta_hash_lock down into rtw_free_stainfo(),
also fixes a whole bunch of callers of rtw_free_stainfo() which
were not holding that lock even though they should.

Note that this also fixes the deadlock from the "remove possible
deadlock when disconnect" patch in a different way. But the
changes from that patch offer a nice locking cleanup regardless.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210920145502.155454-2-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Nov 24, 2021
[ Upstream commit bdc1bbd ]

The assoc_timer takes the pmlmepriv->lock and various functions which
take the pmlmepriv->scanned_queue.lock first take the pmlmepriv->lock,
this means that we cannot have code which waits for the timer
(timer_del_sync) while holding the pmlmepriv->scanned_queue.lock
to avoid a triangle deadlock:

[  363.139361] ======================================================
[  363.139377] WARNING: possible circular locking dependency detected
[  363.139396] 5.15.0-rc1+ torvalds#470 Tainted: G         C  E
[  363.139413] ------------------------------------------------------
[  363.139424] RTW_CMD_THREAD/2466 is trying to acquire lock:
[  363.139441] ffffbacd00699038 (&pmlmepriv->lock){+.-.}-{2:2}, at: _rtw_join_timeout_handler+0x3c/0x160 [r8723bs]
[  363.139598]
               but task is already holding lock:
[  363.139610] ffffbacd00128ea0 ((&pmlmepriv->assoc_timer)){+.-.}-{0:0}, at: call_timer_fn+0x5/0x260
[  363.139673]
               which lock already depends on the new lock.

[  363.139684]
               the existing dependency chain (in reverse order) is:
[  363.139696]
               -> #2 ((&pmlmepriv->assoc_timer)){+.-.}-{0:0}:
[  363.139734]        del_timer_sync+0x59/0x100
[  363.139762]        rtw_joinbss_event_prehandle+0x342/0x640 [r8723bs]
[  363.139870]        report_join_res+0xdf/0x110 [r8723bs]
[  363.139980]        OnAssocRsp+0x17a/0x200 [r8723bs]
[  363.140092]        rtw_recv_entry+0x190/0x1120 [r8723bs]
[  363.140209]        rtl8723b_process_phy_info+0x3f9/0x750 [r8723bs]
[  363.140318]        tasklet_action_common.constprop.0+0xe8/0x110
[  363.140345]        __do_softirq+0xde/0x485
[  363.140372]        __irq_exit_rcu+0xd0/0x100
[  363.140393]        irq_exit_rcu+0xa/0x20
[  363.140413]        common_interrupt+0x83/0xa0
[  363.140440]        asm_common_interrupt+0x1e/0x40
[  363.140463]        finish_task_switch.isra.0+0x157/0x3d0
[  363.140492]        __schedule+0x447/0x1880
[  363.140516]        schedule+0x59/0xc0
[  363.140537]        smpboot_thread_fn+0x161/0x1c0
[  363.140565]        kthread+0x143/0x160
[  363.140585]        ret_from_fork+0x22/0x30
[  363.140614]
               -> #1 (&pmlmepriv->scanned_queue.lock){+.-.}-{2:2}:
[  363.140653]        _raw_spin_lock_bh+0x34/0x40
[  363.140675]        rtw_free_network_queue+0x31/0x80 [r8723bs]
[  363.140776]        rtw_sitesurvey_cmd+0x79/0x1e0 [r8723bs]
[  363.140869]        rtw_cfg80211_surveydone_event_callback+0x3cf/0x470 [r8723bs]
[  363.140973]        rdev_scan+0x42/0x1a0 [cfg80211]
[  363.141307]        nl80211_trigger_scan+0x566/0x660 [cfg80211]
[  363.141635]        genl_family_rcv_msg_doit+0xcd/0x110
[  363.141661]        genl_rcv_msg+0xce/0x1c0
[  363.141680]        netlink_rcv_skb+0x50/0xf0
[  363.141699]        genl_rcv+0x24/0x40
[  363.141717]        netlink_unicast+0x16d/0x230
[  363.141736]        netlink_sendmsg+0x22b/0x450
[  363.141755]        sock_sendmsg+0x5e/0x60
[  363.141781]        ____sys_sendmsg+0x22f/0x270
[  363.141803]        ___sys_sendmsg+0x81/0xc0
[  363.141828]        __sys_sendmsg+0x49/0x80
[  363.141851]        do_syscall_64+0x3b/0x90
[  363.141873]        entry_SYSCALL_64_after_hwframe+0x44/0xae
[  363.141895]
               -> #0 (&pmlmepriv->lock){+.-.}-{2:2}:
[  363.141930]        __lock_acquire+0x1158/0x1de0
[  363.141954]        lock_acquire+0xb5/0x2b0
[  363.141974]        _raw_spin_lock_bh+0x34/0x40
[  363.141993]        _rtw_join_timeout_handler+0x3c/0x160 [r8723bs]
[  363.142097]        call_timer_fn+0x94/0x260
[  363.142122]        __run_timers.part.0+0x1bf/0x290
[  363.142147]        run_timer_softirq+0x26/0x50
[  363.142171]        __do_softirq+0xde/0x485
[  363.142193]        __irq_exit_rcu+0xd0/0x100
[  363.142215]        irq_exit_rcu+0xa/0x20
[  363.142235]        sysvec_apic_timer_interrupt+0x72/0x90
[  363.142260]        asm_sysvec_apic_timer_interrupt+0x12/0x20
[  363.142283]        __module_address.part.0+0x0/0xd0
[  363.142309]        is_module_address+0x25/0x40
[  363.142334]        static_obj+0x4f/0x60
[  363.142361]        lockdep_init_map_type+0x47/0x220
[  363.142382]        __init_swait_queue_head+0x45/0x60
[  363.142408]        mmc_wait_for_req+0x4a/0xc0 [mmc_core]
[  363.142504]        mmc_wait_for_cmd+0x55/0x70 [mmc_core]
[  363.142592]        mmc_io_rw_direct+0x75/0xe0 [mmc_core]
[  363.142691]        sdio_writeb+0x2e/0x50 [mmc_core]
[  363.142788]        _sd_cmd52_write+0x62/0x80 [r8723bs]
[  363.142885]        sd_cmd52_write+0x6c/0xb0 [r8723bs]
[  363.142981]        rtl8723bs_set_hal_ops+0x982/0x9b0 [r8723bs]
[  363.143089]        rtw_write16+0x1e/0x30 [r8723bs]
[  363.143184]        SetHwReg8723B+0xcc9/0xd30 [r8723bs]
[  363.143294]        mlmeext_joinbss_event_callback+0x17a/0x1a0 [r8723bs]
[  363.143405]        rtw_joinbss_event_callback+0x11/0x20 [r8723bs]
[  363.143507]        mlme_evt_hdl+0x4d/0x70 [r8723bs]
[  363.143620]        rtw_cmd_thread+0x168/0x3c0 [r8723bs]
[  363.143712]        kthread+0x143/0x160
[  363.143732]        ret_from_fork+0x22/0x30
[  363.143757]
               other info that might help us debug this:

[  363.143768] Chain exists of:
                 &pmlmepriv->lock --> &pmlmepriv->scanned_queue.lock --> (&pmlmepriv->assoc_timer)

[  363.143809]  Possible unsafe locking scenario:

[  363.143819]        CPU0                    CPU1
[  363.143831]        ----                    ----
[  363.143841]   lock((&pmlmepriv->assoc_timer));
[  363.143862]                                lock(&pmlmepriv->scanned_queue.lock);
[  363.143882]                                lock((&pmlmepriv->assoc_timer));
[  363.143902]   lock(&pmlmepriv->lock);
[  363.143921]
                *** DEADLOCK ***

Make rtw_joinbss_event_prehandle() release the scanned_queue.lock before
it deletes the timer to avoid this (it is still holding pmlmepriv->lock
protecting against racing the timer).

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210920145502.155454-3-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Nov 24, 2021
[ Upstream commit a7ac783 ]

Lockdep complains about rtw_free_assoc_resources() taking the sta_hash_lock
followed by it calling rtw_free_stainfo() which takes xmitpriv->lock.
While the rtl8723bs_xmit_thread takes the sta_hash_lock while already
holding the xmitpriv->lock:

[  103.849756] ======================================================
[  103.849761] WARNING: possible circular locking dependency detected
[  103.849767] 5.15.0-rc1+ torvalds#470 Tainted: G         C  E
[  103.849773] ------------------------------------------------------
[  103.849776] wpa_supplicant/695 is trying to acquire lock:
[  103.849781] ffffa5d0c0562b00 (&pxmitpriv->lock){+.-.}-{2:2}, at: rtw_free_stainfo+0x8a/0x510 [r8723bs]
[  103.849840]
               but task is already holding lock:
[  103.849843] ffffa5d0c05636a8 (&pstapriv->sta_hash_lock){+.-.}-{2:2}, at: rtw_free_assoc_resources+0x48/0x110 [r8723bs]
[  103.849881]
               which lock already depends on the new lock.

[  103.849884]
               the existing dependency chain (in reverse order) is:
[  103.849887]
               -> #1 (&pstapriv->sta_hash_lock){+.-.}-{2:2}:
[  103.849898]        _raw_spin_lock_bh+0x34/0x40
[  103.849913]        rtw_get_stainfo+0x93/0x110 [r8723bs]
[  103.849948]        rtw_make_wlanhdr+0x14a/0x270 [r8723bs]
[  103.849983]        rtw_xmitframe_coalesce+0x5c/0x6c0 [r8723bs]
[  103.850019]        rtl8723bs_xmit_thread+0x4ac/0x620 [r8723bs]
[  103.850050]        kthread+0x143/0x160
[  103.850058]        ret_from_fork+0x22/0x30
[  103.850067]
               -> #0 (&pxmitpriv->lock){+.-.}-{2:2}:
[  103.850077]        __lock_acquire+0x1158/0x1de0
[  103.850084]        lock_acquire+0xb5/0x2b0
[  103.850090]        _raw_spin_lock_bh+0x34/0x40
[  103.850095]        rtw_free_stainfo+0x8a/0x510 [r8723bs]
[  103.850130]        rtw_free_assoc_resources+0x53/0x110 [r8723bs]
[  103.850159]        PHY_IQCalibrate_8723B+0x122b/0x36a0 [r8723bs]
[  103.850189]        cfg80211_disconnect+0x173/0x320 [cfg80211]
[  103.850331]        nl80211_disconnect+0x6e/0xb0 [cfg80211]
[  103.850422]        genl_family_rcv_msg_doit+0xcd/0x110
[  103.850430]        genl_rcv_msg+0xce/0x1c0
[  103.850435]        netlink_rcv_skb+0x50/0xf0
[  103.850441]        genl_rcv+0x24/0x40
[  103.850446]        netlink_unicast+0x16d/0x230
[  103.850452]        netlink_sendmsg+0x22b/0x450
[  103.850457]        sock_sendmsg+0x5e/0x60
[  103.850465]        ____sys_sendmsg+0x22f/0x270
[  103.850472]        ___sys_sendmsg+0x81/0xc0
[  103.850479]        __sys_sendmsg+0x49/0x80
[  103.850485]        do_syscall_64+0x3b/0x90
[  103.850493]        entry_SYSCALL_64_after_hwframe+0x44/0xae
[  103.850500]
               other info that might help us debug this:

[  103.850504]  Possible unsafe locking scenario:

[  103.850507]        CPU0                    CPU1
[  103.850510]        ----                    ----
[  103.850512]   lock(&pstapriv->sta_hash_lock);
[  103.850518]                                lock(&pxmitpriv->lock);
[  103.850524]                                lock(&pstapriv->sta_hash_lock);
[  103.850530]   lock(&pxmitpriv->lock);
[  103.850535]
                *** DEADLOCK ***

Push the taking of sta_hash_lock down into rtw_free_stainfo(),
where the critical section is, this allows taking the lock after
rtw_free_stainfo() has released pxmitpriv->lock.

This requires changing rtw_free_all_stainfo() so that it does its freeing
in 2 steps, first moving all stainfo-s to free to a local list while
holding the sta_hash_lock and then walking that list to call
rtw_free_stainfo() on them without holding the sta_hash_lock.

Pushing the taking of sta_hash_lock down into rtw_free_stainfo(),
also fixes a whole bunch of callers of rtw_free_stainfo() which
were not holding that lock even though they should.

Note that this also fixes the deadlock from the "remove possible
deadlock when disconnect" patch in a different way. But the
changes from that patch offer a nice locking cleanup regardless.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210920145502.155454-2-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Nov 24, 2021
[ Upstream commit bdc1bbd ]

The assoc_timer takes the pmlmepriv->lock and various functions which
take the pmlmepriv->scanned_queue.lock first take the pmlmepriv->lock,
this means that we cannot have code which waits for the timer
(timer_del_sync) while holding the pmlmepriv->scanned_queue.lock
to avoid a triangle deadlock:

[  363.139361] ======================================================
[  363.139377] WARNING: possible circular locking dependency detected
[  363.139396] 5.15.0-rc1+ torvalds#470 Tainted: G         C  E
[  363.139413] ------------------------------------------------------
[  363.139424] RTW_CMD_THREAD/2466 is trying to acquire lock:
[  363.139441] ffffbacd00699038 (&pmlmepriv->lock){+.-.}-{2:2}, at: _rtw_join_timeout_handler+0x3c/0x160 [r8723bs]
[  363.139598]
               but task is already holding lock:
[  363.139610] ffffbacd00128ea0 ((&pmlmepriv->assoc_timer)){+.-.}-{0:0}, at: call_timer_fn+0x5/0x260
[  363.139673]
               which lock already depends on the new lock.

[  363.139684]
               the existing dependency chain (in reverse order) is:
[  363.139696]
               -> #2 ((&pmlmepriv->assoc_timer)){+.-.}-{0:0}:
[  363.139734]        del_timer_sync+0x59/0x100
[  363.139762]        rtw_joinbss_event_prehandle+0x342/0x640 [r8723bs]
[  363.139870]        report_join_res+0xdf/0x110 [r8723bs]
[  363.139980]        OnAssocRsp+0x17a/0x200 [r8723bs]
[  363.140092]        rtw_recv_entry+0x190/0x1120 [r8723bs]
[  363.140209]        rtl8723b_process_phy_info+0x3f9/0x750 [r8723bs]
[  363.140318]        tasklet_action_common.constprop.0+0xe8/0x110
[  363.140345]        __do_softirq+0xde/0x485
[  363.140372]        __irq_exit_rcu+0xd0/0x100
[  363.140393]        irq_exit_rcu+0xa/0x20
[  363.140413]        common_interrupt+0x83/0xa0
[  363.140440]        asm_common_interrupt+0x1e/0x40
[  363.140463]        finish_task_switch.isra.0+0x157/0x3d0
[  363.140492]        __schedule+0x447/0x1880
[  363.140516]        schedule+0x59/0xc0
[  363.140537]        smpboot_thread_fn+0x161/0x1c0
[  363.140565]        kthread+0x143/0x160
[  363.140585]        ret_from_fork+0x22/0x30
[  363.140614]
               -> #1 (&pmlmepriv->scanned_queue.lock){+.-.}-{2:2}:
[  363.140653]        _raw_spin_lock_bh+0x34/0x40
[  363.140675]        rtw_free_network_queue+0x31/0x80 [r8723bs]
[  363.140776]        rtw_sitesurvey_cmd+0x79/0x1e0 [r8723bs]
[  363.140869]        rtw_cfg80211_surveydone_event_callback+0x3cf/0x470 [r8723bs]
[  363.140973]        rdev_scan+0x42/0x1a0 [cfg80211]
[  363.141307]        nl80211_trigger_scan+0x566/0x660 [cfg80211]
[  363.141635]        genl_family_rcv_msg_doit+0xcd/0x110
[  363.141661]        genl_rcv_msg+0xce/0x1c0
[  363.141680]        netlink_rcv_skb+0x50/0xf0
[  363.141699]        genl_rcv+0x24/0x40
[  363.141717]        netlink_unicast+0x16d/0x230
[  363.141736]        netlink_sendmsg+0x22b/0x450
[  363.141755]        sock_sendmsg+0x5e/0x60
[  363.141781]        ____sys_sendmsg+0x22f/0x270
[  363.141803]        ___sys_sendmsg+0x81/0xc0
[  363.141828]        __sys_sendmsg+0x49/0x80
[  363.141851]        do_syscall_64+0x3b/0x90
[  363.141873]        entry_SYSCALL_64_after_hwframe+0x44/0xae
[  363.141895]
               -> #0 (&pmlmepriv->lock){+.-.}-{2:2}:
[  363.141930]        __lock_acquire+0x1158/0x1de0
[  363.141954]        lock_acquire+0xb5/0x2b0
[  363.141974]        _raw_spin_lock_bh+0x34/0x40
[  363.141993]        _rtw_join_timeout_handler+0x3c/0x160 [r8723bs]
[  363.142097]        call_timer_fn+0x94/0x260
[  363.142122]        __run_timers.part.0+0x1bf/0x290
[  363.142147]        run_timer_softirq+0x26/0x50
[  363.142171]        __do_softirq+0xde/0x485
[  363.142193]        __irq_exit_rcu+0xd0/0x100
[  363.142215]        irq_exit_rcu+0xa/0x20
[  363.142235]        sysvec_apic_timer_interrupt+0x72/0x90
[  363.142260]        asm_sysvec_apic_timer_interrupt+0x12/0x20
[  363.142283]        __module_address.part.0+0x0/0xd0
[  363.142309]        is_module_address+0x25/0x40
[  363.142334]        static_obj+0x4f/0x60
[  363.142361]        lockdep_init_map_type+0x47/0x220
[  363.142382]        __init_swait_queue_head+0x45/0x60
[  363.142408]        mmc_wait_for_req+0x4a/0xc0 [mmc_core]
[  363.142504]        mmc_wait_for_cmd+0x55/0x70 [mmc_core]
[  363.142592]        mmc_io_rw_direct+0x75/0xe0 [mmc_core]
[  363.142691]        sdio_writeb+0x2e/0x50 [mmc_core]
[  363.142788]        _sd_cmd52_write+0x62/0x80 [r8723bs]
[  363.142885]        sd_cmd52_write+0x6c/0xb0 [r8723bs]
[  363.142981]        rtl8723bs_set_hal_ops+0x982/0x9b0 [r8723bs]
[  363.143089]        rtw_write16+0x1e/0x30 [r8723bs]
[  363.143184]        SetHwReg8723B+0xcc9/0xd30 [r8723bs]
[  363.143294]        mlmeext_joinbss_event_callback+0x17a/0x1a0 [r8723bs]
[  363.143405]        rtw_joinbss_event_callback+0x11/0x20 [r8723bs]
[  363.143507]        mlme_evt_hdl+0x4d/0x70 [r8723bs]
[  363.143620]        rtw_cmd_thread+0x168/0x3c0 [r8723bs]
[  363.143712]        kthread+0x143/0x160
[  363.143732]        ret_from_fork+0x22/0x30
[  363.143757]
               other info that might help us debug this:

[  363.143768] Chain exists of:
                 &pmlmepriv->lock --> &pmlmepriv->scanned_queue.lock --> (&pmlmepriv->assoc_timer)

[  363.143809]  Possible unsafe locking scenario:

[  363.143819]        CPU0                    CPU1
[  363.143831]        ----                    ----
[  363.143841]   lock((&pmlmepriv->assoc_timer));
[  363.143862]                                lock(&pmlmepriv->scanned_queue.lock);
[  363.143882]                                lock((&pmlmepriv->assoc_timer));
[  363.143902]   lock(&pmlmepriv->lock);
[  363.143921]
                *** DEADLOCK ***

Make rtw_joinbss_event_prehandle() release the scanned_queue.lock before
it deletes the timer to avoid this (it is still holding pmlmepriv->lock
protecting against racing the timer).

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210920145502.155454-3-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Nov 24, 2021
[ Upstream commit a7ac783 ]

Lockdep complains about rtw_free_assoc_resources() taking the sta_hash_lock
followed by it calling rtw_free_stainfo() which takes xmitpriv->lock.
While the rtl8723bs_xmit_thread takes the sta_hash_lock while already
holding the xmitpriv->lock:

[  103.849756] ======================================================
[  103.849761] WARNING: possible circular locking dependency detected
[  103.849767] 5.15.0-rc1+ torvalds#470 Tainted: G         C  E
[  103.849773] ------------------------------------------------------
[  103.849776] wpa_supplicant/695 is trying to acquire lock:
[  103.849781] ffffa5d0c0562b00 (&pxmitpriv->lock){+.-.}-{2:2}, at: rtw_free_stainfo+0x8a/0x510 [r8723bs]
[  103.849840]
               but task is already holding lock:
[  103.849843] ffffa5d0c05636a8 (&pstapriv->sta_hash_lock){+.-.}-{2:2}, at: rtw_free_assoc_resources+0x48/0x110 [r8723bs]
[  103.849881]
               which lock already depends on the new lock.

[  103.849884]
               the existing dependency chain (in reverse order) is:
[  103.849887]
               -> #1 (&pstapriv->sta_hash_lock){+.-.}-{2:2}:
[  103.849898]        _raw_spin_lock_bh+0x34/0x40
[  103.849913]        rtw_get_stainfo+0x93/0x110 [r8723bs]
[  103.849948]        rtw_make_wlanhdr+0x14a/0x270 [r8723bs]
[  103.849983]        rtw_xmitframe_coalesce+0x5c/0x6c0 [r8723bs]
[  103.850019]        rtl8723bs_xmit_thread+0x4ac/0x620 [r8723bs]
[  103.850050]        kthread+0x143/0x160
[  103.850058]        ret_from_fork+0x22/0x30
[  103.850067]
               -> #0 (&pxmitpriv->lock){+.-.}-{2:2}:
[  103.850077]        __lock_acquire+0x1158/0x1de0
[  103.850084]        lock_acquire+0xb5/0x2b0
[  103.850090]        _raw_spin_lock_bh+0x34/0x40
[  103.850095]        rtw_free_stainfo+0x8a/0x510 [r8723bs]
[  103.850130]        rtw_free_assoc_resources+0x53/0x110 [r8723bs]
[  103.850159]        PHY_IQCalibrate_8723B+0x122b/0x36a0 [r8723bs]
[  103.850189]        cfg80211_disconnect+0x173/0x320 [cfg80211]
[  103.850331]        nl80211_disconnect+0x6e/0xb0 [cfg80211]
[  103.850422]        genl_family_rcv_msg_doit+0xcd/0x110
[  103.850430]        genl_rcv_msg+0xce/0x1c0
[  103.850435]        netlink_rcv_skb+0x50/0xf0
[  103.850441]        genl_rcv+0x24/0x40
[  103.850446]        netlink_unicast+0x16d/0x230
[  103.850452]        netlink_sendmsg+0x22b/0x450
[  103.850457]        sock_sendmsg+0x5e/0x60
[  103.850465]        ____sys_sendmsg+0x22f/0x270
[  103.850472]        ___sys_sendmsg+0x81/0xc0
[  103.850479]        __sys_sendmsg+0x49/0x80
[  103.850485]        do_syscall_64+0x3b/0x90
[  103.850493]        entry_SYSCALL_64_after_hwframe+0x44/0xae
[  103.850500]
               other info that might help us debug this:

[  103.850504]  Possible unsafe locking scenario:

[  103.850507]        CPU0                    CPU1
[  103.850510]        ----                    ----
[  103.850512]   lock(&pstapriv->sta_hash_lock);
[  103.850518]                                lock(&pxmitpriv->lock);
[  103.850524]                                lock(&pstapriv->sta_hash_lock);
[  103.850530]   lock(&pxmitpriv->lock);
[  103.850535]
                *** DEADLOCK ***

Push the taking of sta_hash_lock down into rtw_free_stainfo(),
where the critical section is, this allows taking the lock after
rtw_free_stainfo() has released pxmitpriv->lock.

This requires changing rtw_free_all_stainfo() so that it does its freeing
in 2 steps, first moving all stainfo-s to free to a local list while
holding the sta_hash_lock and then walking that list to call
rtw_free_stainfo() on them without holding the sta_hash_lock.

Pushing the taking of sta_hash_lock down into rtw_free_stainfo(),
also fixes a whole bunch of callers of rtw_free_stainfo() which
were not holding that lock even though they should.

Note that this also fixes the deadlock from the "remove possible
deadlock when disconnect" patch in a different way. But the
changes from that patch offer a nice locking cleanup regardless.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210920145502.155454-2-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Nov 24, 2021
[ Upstream commit bdc1bbd ]

The assoc_timer takes the pmlmepriv->lock and various functions which
take the pmlmepriv->scanned_queue.lock first take the pmlmepriv->lock,
this means that we cannot have code which waits for the timer
(timer_del_sync) while holding the pmlmepriv->scanned_queue.lock
to avoid a triangle deadlock:

[  363.139361] ======================================================
[  363.139377] WARNING: possible circular locking dependency detected
[  363.139396] 5.15.0-rc1+ torvalds#470 Tainted: G         C  E
[  363.139413] ------------------------------------------------------
[  363.139424] RTW_CMD_THREAD/2466 is trying to acquire lock:
[  363.139441] ffffbacd00699038 (&pmlmepriv->lock){+.-.}-{2:2}, at: _rtw_join_timeout_handler+0x3c/0x160 [r8723bs]
[  363.139598]
               but task is already holding lock:
[  363.139610] ffffbacd00128ea0 ((&pmlmepriv->assoc_timer)){+.-.}-{0:0}, at: call_timer_fn+0x5/0x260
[  363.139673]
               which lock already depends on the new lock.

[  363.139684]
               the existing dependency chain (in reverse order) is:
[  363.139696]
               -> #2 ((&pmlmepriv->assoc_timer)){+.-.}-{0:0}:
[  363.139734]        del_timer_sync+0x59/0x100
[  363.139762]        rtw_joinbss_event_prehandle+0x342/0x640 [r8723bs]
[  363.139870]        report_join_res+0xdf/0x110 [r8723bs]
[  363.139980]        OnAssocRsp+0x17a/0x200 [r8723bs]
[  363.140092]        rtw_recv_entry+0x190/0x1120 [r8723bs]
[  363.140209]        rtl8723b_process_phy_info+0x3f9/0x750 [r8723bs]
[  363.140318]        tasklet_action_common.constprop.0+0xe8/0x110
[  363.140345]        __do_softirq+0xde/0x485
[  363.140372]        __irq_exit_rcu+0xd0/0x100
[  363.140393]        irq_exit_rcu+0xa/0x20
[  363.140413]        common_interrupt+0x83/0xa0
[  363.140440]        asm_common_interrupt+0x1e/0x40
[  363.140463]        finish_task_switch.isra.0+0x157/0x3d0
[  363.140492]        __schedule+0x447/0x1880
[  363.140516]        schedule+0x59/0xc0
[  363.140537]        smpboot_thread_fn+0x161/0x1c0
[  363.140565]        kthread+0x143/0x160
[  363.140585]        ret_from_fork+0x22/0x30
[  363.140614]
               -> #1 (&pmlmepriv->scanned_queue.lock){+.-.}-{2:2}:
[  363.140653]        _raw_spin_lock_bh+0x34/0x40
[  363.140675]        rtw_free_network_queue+0x31/0x80 [r8723bs]
[  363.140776]        rtw_sitesurvey_cmd+0x79/0x1e0 [r8723bs]
[  363.140869]        rtw_cfg80211_surveydone_event_callback+0x3cf/0x470 [r8723bs]
[  363.140973]        rdev_scan+0x42/0x1a0 [cfg80211]
[  363.141307]        nl80211_trigger_scan+0x566/0x660 [cfg80211]
[  363.141635]        genl_family_rcv_msg_doit+0xcd/0x110
[  363.141661]        genl_rcv_msg+0xce/0x1c0
[  363.141680]        netlink_rcv_skb+0x50/0xf0
[  363.141699]        genl_rcv+0x24/0x40
[  363.141717]        netlink_unicast+0x16d/0x230
[  363.141736]        netlink_sendmsg+0x22b/0x450
[  363.141755]        sock_sendmsg+0x5e/0x60
[  363.141781]        ____sys_sendmsg+0x22f/0x270
[  363.141803]        ___sys_sendmsg+0x81/0xc0
[  363.141828]        __sys_sendmsg+0x49/0x80
[  363.141851]        do_syscall_64+0x3b/0x90
[  363.141873]        entry_SYSCALL_64_after_hwframe+0x44/0xae
[  363.141895]
               -> #0 (&pmlmepriv->lock){+.-.}-{2:2}:
[  363.141930]        __lock_acquire+0x1158/0x1de0
[  363.141954]        lock_acquire+0xb5/0x2b0
[  363.141974]        _raw_spin_lock_bh+0x34/0x40
[  363.141993]        _rtw_join_timeout_handler+0x3c/0x160 [r8723bs]
[  363.142097]        call_timer_fn+0x94/0x260
[  363.142122]        __run_timers.part.0+0x1bf/0x290
[  363.142147]        run_timer_softirq+0x26/0x50
[  363.142171]        __do_softirq+0xde/0x485
[  363.142193]        __irq_exit_rcu+0xd0/0x100
[  363.142215]        irq_exit_rcu+0xa/0x20
[  363.142235]        sysvec_apic_timer_interrupt+0x72/0x90
[  363.142260]        asm_sysvec_apic_timer_interrupt+0x12/0x20
[  363.142283]        __module_address.part.0+0x0/0xd0
[  363.142309]        is_module_address+0x25/0x40
[  363.142334]        static_obj+0x4f/0x60
[  363.142361]        lockdep_init_map_type+0x47/0x220
[  363.142382]        __init_swait_queue_head+0x45/0x60
[  363.142408]        mmc_wait_for_req+0x4a/0xc0 [mmc_core]
[  363.142504]        mmc_wait_for_cmd+0x55/0x70 [mmc_core]
[  363.142592]        mmc_io_rw_direct+0x75/0xe0 [mmc_core]
[  363.142691]        sdio_writeb+0x2e/0x50 [mmc_core]
[  363.142788]        _sd_cmd52_write+0x62/0x80 [r8723bs]
[  363.142885]        sd_cmd52_write+0x6c/0xb0 [r8723bs]
[  363.142981]        rtl8723bs_set_hal_ops+0x982/0x9b0 [r8723bs]
[  363.143089]        rtw_write16+0x1e/0x30 [r8723bs]
[  363.143184]        SetHwReg8723B+0xcc9/0xd30 [r8723bs]
[  363.143294]        mlmeext_joinbss_event_callback+0x17a/0x1a0 [r8723bs]
[  363.143405]        rtw_joinbss_event_callback+0x11/0x20 [r8723bs]
[  363.143507]        mlme_evt_hdl+0x4d/0x70 [r8723bs]
[  363.143620]        rtw_cmd_thread+0x168/0x3c0 [r8723bs]
[  363.143712]        kthread+0x143/0x160
[  363.143732]        ret_from_fork+0x22/0x30
[  363.143757]
               other info that might help us debug this:

[  363.143768] Chain exists of:
                 &pmlmepriv->lock --> &pmlmepriv->scanned_queue.lock --> (&pmlmepriv->assoc_timer)

[  363.143809]  Possible unsafe locking scenario:

[  363.143819]        CPU0                    CPU1
[  363.143831]        ----                    ----
[  363.143841]   lock((&pmlmepriv->assoc_timer));
[  363.143862]                                lock(&pmlmepriv->scanned_queue.lock);
[  363.143882]                                lock((&pmlmepriv->assoc_timer));
[  363.143902]   lock(&pmlmepriv->lock);
[  363.143921]
                *** DEADLOCK ***

Make rtw_joinbss_event_prehandle() release the scanned_queue.lock before
it deletes the timer to avoid this (it is still holding pmlmepriv->lock
protecting against racing the timer).

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210920145502.155454-3-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Nov 25, 2021
[ Upstream commit a7ac783 ]

Lockdep complains about rtw_free_assoc_resources() taking the sta_hash_lock
followed by it calling rtw_free_stainfo() which takes xmitpriv->lock.
While the rtl8723bs_xmit_thread takes the sta_hash_lock while already
holding the xmitpriv->lock:

[  103.849756] ======================================================
[  103.849761] WARNING: possible circular locking dependency detected
[  103.849767] 5.15.0-rc1+ torvalds#470 Tainted: G         C  E
[  103.849773] ------------------------------------------------------
[  103.849776] wpa_supplicant/695 is trying to acquire lock:
[  103.849781] ffffa5d0c0562b00 (&pxmitpriv->lock){+.-.}-{2:2}, at: rtw_free_stainfo+0x8a/0x510 [r8723bs]
[  103.849840]
               but task is already holding lock:
[  103.849843] ffffa5d0c05636a8 (&pstapriv->sta_hash_lock){+.-.}-{2:2}, at: rtw_free_assoc_resources+0x48/0x110 [r8723bs]
[  103.849881]
               which lock already depends on the new lock.

[  103.849884]
               the existing dependency chain (in reverse order) is:
[  103.849887]
               -> #1 (&pstapriv->sta_hash_lock){+.-.}-{2:2}:
[  103.849898]        _raw_spin_lock_bh+0x34/0x40
[  103.849913]        rtw_get_stainfo+0x93/0x110 [r8723bs]
[  103.849948]        rtw_make_wlanhdr+0x14a/0x270 [r8723bs]
[  103.849983]        rtw_xmitframe_coalesce+0x5c/0x6c0 [r8723bs]
[  103.850019]        rtl8723bs_xmit_thread+0x4ac/0x620 [r8723bs]
[  103.850050]        kthread+0x143/0x160
[  103.850058]        ret_from_fork+0x22/0x30
[  103.850067]
               -> #0 (&pxmitpriv->lock){+.-.}-{2:2}:
[  103.850077]        __lock_acquire+0x1158/0x1de0
[  103.850084]        lock_acquire+0xb5/0x2b0
[  103.850090]        _raw_spin_lock_bh+0x34/0x40
[  103.850095]        rtw_free_stainfo+0x8a/0x510 [r8723bs]
[  103.850130]        rtw_free_assoc_resources+0x53/0x110 [r8723bs]
[  103.850159]        PHY_IQCalibrate_8723B+0x122b/0x36a0 [r8723bs]
[  103.850189]        cfg80211_disconnect+0x173/0x320 [cfg80211]
[  103.850331]        nl80211_disconnect+0x6e/0xb0 [cfg80211]
[  103.850422]        genl_family_rcv_msg_doit+0xcd/0x110
[  103.850430]        genl_rcv_msg+0xce/0x1c0
[  103.850435]        netlink_rcv_skb+0x50/0xf0
[  103.850441]        genl_rcv+0x24/0x40
[  103.850446]        netlink_unicast+0x16d/0x230
[  103.850452]        netlink_sendmsg+0x22b/0x450
[  103.850457]        sock_sendmsg+0x5e/0x60
[  103.850465]        ____sys_sendmsg+0x22f/0x270
[  103.850472]        ___sys_sendmsg+0x81/0xc0
[  103.850479]        __sys_sendmsg+0x49/0x80
[  103.850485]        do_syscall_64+0x3b/0x90
[  103.850493]        entry_SYSCALL_64_after_hwframe+0x44/0xae
[  103.850500]
               other info that might help us debug this:

[  103.850504]  Possible unsafe locking scenario:

[  103.850507]        CPU0                    CPU1
[  103.850510]        ----                    ----
[  103.850512]   lock(&pstapriv->sta_hash_lock);
[  103.850518]                                lock(&pxmitpriv->lock);
[  103.850524]                                lock(&pstapriv->sta_hash_lock);
[  103.850530]   lock(&pxmitpriv->lock);
[  103.850535]
                *** DEADLOCK ***

Push the taking of sta_hash_lock down into rtw_free_stainfo(),
where the critical section is, this allows taking the lock after
rtw_free_stainfo() has released pxmitpriv->lock.

This requires changing rtw_free_all_stainfo() so that it does its freeing
in 2 steps, first moving all stainfo-s to free to a local list while
holding the sta_hash_lock and then walking that list to call
rtw_free_stainfo() on them without holding the sta_hash_lock.

Pushing the taking of sta_hash_lock down into rtw_free_stainfo(),
also fixes a whole bunch of callers of rtw_free_stainfo() which
were not holding that lock even though they should.

Note that this also fixes the deadlock from the "remove possible
deadlock when disconnect" patch in a different way. But the
changes from that patch offer a nice locking cleanup regardless.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210920145502.155454-2-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Nov 25, 2021
[ Upstream commit bdc1bbd ]

The assoc_timer takes the pmlmepriv->lock and various functions which
take the pmlmepriv->scanned_queue.lock first take the pmlmepriv->lock,
this means that we cannot have code which waits for the timer
(timer_del_sync) while holding the pmlmepriv->scanned_queue.lock
to avoid a triangle deadlock:

[  363.139361] ======================================================
[  363.139377] WARNING: possible circular locking dependency detected
[  363.139396] 5.15.0-rc1+ torvalds#470 Tainted: G         C  E
[  363.139413] ------------------------------------------------------
[  363.139424] RTW_CMD_THREAD/2466 is trying to acquire lock:
[  363.139441] ffffbacd00699038 (&pmlmepriv->lock){+.-.}-{2:2}, at: _rtw_join_timeout_handler+0x3c/0x160 [r8723bs]
[  363.139598]
               but task is already holding lock:
[  363.139610] ffffbacd00128ea0 ((&pmlmepriv->assoc_timer)){+.-.}-{0:0}, at: call_timer_fn+0x5/0x260
[  363.139673]
               which lock already depends on the new lock.

[  363.139684]
               the existing dependency chain (in reverse order) is:
[  363.139696]
               -> #2 ((&pmlmepriv->assoc_timer)){+.-.}-{0:0}:
[  363.139734]        del_timer_sync+0x59/0x100
[  363.139762]        rtw_joinbss_event_prehandle+0x342/0x640 [r8723bs]
[  363.139870]        report_join_res+0xdf/0x110 [r8723bs]
[  363.139980]        OnAssocRsp+0x17a/0x200 [r8723bs]
[  363.140092]        rtw_recv_entry+0x190/0x1120 [r8723bs]
[  363.140209]        rtl8723b_process_phy_info+0x3f9/0x750 [r8723bs]
[  363.140318]        tasklet_action_common.constprop.0+0xe8/0x110
[  363.140345]        __do_softirq+0xde/0x485
[  363.140372]        __irq_exit_rcu+0xd0/0x100
[  363.140393]        irq_exit_rcu+0xa/0x20
[  363.140413]        common_interrupt+0x83/0xa0
[  363.140440]        asm_common_interrupt+0x1e/0x40
[  363.140463]        finish_task_switch.isra.0+0x157/0x3d0
[  363.140492]        __schedule+0x447/0x1880
[  363.140516]        schedule+0x59/0xc0
[  363.140537]        smpboot_thread_fn+0x161/0x1c0
[  363.140565]        kthread+0x143/0x160
[  363.140585]        ret_from_fork+0x22/0x30
[  363.140614]
               -> #1 (&pmlmepriv->scanned_queue.lock){+.-.}-{2:2}:
[  363.140653]        _raw_spin_lock_bh+0x34/0x40
[  363.140675]        rtw_free_network_queue+0x31/0x80 [r8723bs]
[  363.140776]        rtw_sitesurvey_cmd+0x79/0x1e0 [r8723bs]
[  363.140869]        rtw_cfg80211_surveydone_event_callback+0x3cf/0x470 [r8723bs]
[  363.140973]        rdev_scan+0x42/0x1a0 [cfg80211]
[  363.141307]        nl80211_trigger_scan+0x566/0x660 [cfg80211]
[  363.141635]        genl_family_rcv_msg_doit+0xcd/0x110
[  363.141661]        genl_rcv_msg+0xce/0x1c0
[  363.141680]        netlink_rcv_skb+0x50/0xf0
[  363.141699]        genl_rcv+0x24/0x40
[  363.141717]        netlink_unicast+0x16d/0x230
[  363.141736]        netlink_sendmsg+0x22b/0x450
[  363.141755]        sock_sendmsg+0x5e/0x60
[  363.141781]        ____sys_sendmsg+0x22f/0x270
[  363.141803]        ___sys_sendmsg+0x81/0xc0
[  363.141828]        __sys_sendmsg+0x49/0x80
[  363.141851]        do_syscall_64+0x3b/0x90
[  363.141873]        entry_SYSCALL_64_after_hwframe+0x44/0xae
[  363.141895]
               -> #0 (&pmlmepriv->lock){+.-.}-{2:2}:
[  363.141930]        __lock_acquire+0x1158/0x1de0
[  363.141954]        lock_acquire+0xb5/0x2b0
[  363.141974]        _raw_spin_lock_bh+0x34/0x40
[  363.141993]        _rtw_join_timeout_handler+0x3c/0x160 [r8723bs]
[  363.142097]        call_timer_fn+0x94/0x260
[  363.142122]        __run_timers.part.0+0x1bf/0x290
[  363.142147]        run_timer_softirq+0x26/0x50
[  363.142171]        __do_softirq+0xde/0x485
[  363.142193]        __irq_exit_rcu+0xd0/0x100
[  363.142215]        irq_exit_rcu+0xa/0x20
[  363.142235]        sysvec_apic_timer_interrupt+0x72/0x90
[  363.142260]        asm_sysvec_apic_timer_interrupt+0x12/0x20
[  363.142283]        __module_address.part.0+0x0/0xd0
[  363.142309]        is_module_address+0x25/0x40
[  363.142334]        static_obj+0x4f/0x60
[  363.142361]        lockdep_init_map_type+0x47/0x220
[  363.142382]        __init_swait_queue_head+0x45/0x60
[  363.142408]        mmc_wait_for_req+0x4a/0xc0 [mmc_core]
[  363.142504]        mmc_wait_for_cmd+0x55/0x70 [mmc_core]
[  363.142592]        mmc_io_rw_direct+0x75/0xe0 [mmc_core]
[  363.142691]        sdio_writeb+0x2e/0x50 [mmc_core]
[  363.142788]        _sd_cmd52_write+0x62/0x80 [r8723bs]
[  363.142885]        sd_cmd52_write+0x6c/0xb0 [r8723bs]
[  363.142981]        rtl8723bs_set_hal_ops+0x982/0x9b0 [r8723bs]
[  363.143089]        rtw_write16+0x1e/0x30 [r8723bs]
[  363.143184]        SetHwReg8723B+0xcc9/0xd30 [r8723bs]
[  363.143294]        mlmeext_joinbss_event_callback+0x17a/0x1a0 [r8723bs]
[  363.143405]        rtw_joinbss_event_callback+0x11/0x20 [r8723bs]
[  363.143507]        mlme_evt_hdl+0x4d/0x70 [r8723bs]
[  363.143620]        rtw_cmd_thread+0x168/0x3c0 [r8723bs]
[  363.143712]        kthread+0x143/0x160
[  363.143732]        ret_from_fork+0x22/0x30
[  363.143757]
               other info that might help us debug this:

[  363.143768] Chain exists of:
                 &pmlmepriv->lock --> &pmlmepriv->scanned_queue.lock --> (&pmlmepriv->assoc_timer)

[  363.143809]  Possible unsafe locking scenario:

[  363.143819]        CPU0                    CPU1
[  363.143831]        ----                    ----
[  363.143841]   lock((&pmlmepriv->assoc_timer));
[  363.143862]                                lock(&pmlmepriv->scanned_queue.lock);
[  363.143882]                                lock((&pmlmepriv->assoc_timer));
[  363.143902]   lock(&pmlmepriv->lock);
[  363.143921]
                *** DEADLOCK ***

Make rtw_joinbss_event_prehandle() release the scanned_queue.lock before
it deletes the timer to avoid this (it is still holding pmlmepriv->lock
protecting against racing the timer).

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210920145502.155454-3-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Nov 25, 2021
[ Upstream commit a7ac783 ]

Lockdep complains about rtw_free_assoc_resources() taking the sta_hash_lock
followed by it calling rtw_free_stainfo() which takes xmitpriv->lock.
While the rtl8723bs_xmit_thread takes the sta_hash_lock while already
holding the xmitpriv->lock:

[  103.849756] ======================================================
[  103.849761] WARNING: possible circular locking dependency detected
[  103.849767] 5.15.0-rc1+ torvalds#470 Tainted: G         C  E
[  103.849773] ------------------------------------------------------
[  103.849776] wpa_supplicant/695 is trying to acquire lock:
[  103.849781] ffffa5d0c0562b00 (&pxmitpriv->lock){+.-.}-{2:2}, at: rtw_free_stainfo+0x8a/0x510 [r8723bs]
[  103.849840]
               but task is already holding lock:
[  103.849843] ffffa5d0c05636a8 (&pstapriv->sta_hash_lock){+.-.}-{2:2}, at: rtw_free_assoc_resources+0x48/0x110 [r8723bs]
[  103.849881]
               which lock already depends on the new lock.

[  103.849884]
               the existing dependency chain (in reverse order) is:
[  103.849887]
               -> #1 (&pstapriv->sta_hash_lock){+.-.}-{2:2}:
[  103.849898]        _raw_spin_lock_bh+0x34/0x40
[  103.849913]        rtw_get_stainfo+0x93/0x110 [r8723bs]
[  103.849948]        rtw_make_wlanhdr+0x14a/0x270 [r8723bs]
[  103.849983]        rtw_xmitframe_coalesce+0x5c/0x6c0 [r8723bs]
[  103.850019]        rtl8723bs_xmit_thread+0x4ac/0x620 [r8723bs]
[  103.850050]        kthread+0x143/0x160
[  103.850058]        ret_from_fork+0x22/0x30
[  103.850067]
               -> #0 (&pxmitpriv->lock){+.-.}-{2:2}:
[  103.850077]        __lock_acquire+0x1158/0x1de0
[  103.850084]        lock_acquire+0xb5/0x2b0
[  103.850090]        _raw_spin_lock_bh+0x34/0x40
[  103.850095]        rtw_free_stainfo+0x8a/0x510 [r8723bs]
[  103.850130]        rtw_free_assoc_resources+0x53/0x110 [r8723bs]
[  103.850159]        PHY_IQCalibrate_8723B+0x122b/0x36a0 [r8723bs]
[  103.850189]        cfg80211_disconnect+0x173/0x320 [cfg80211]
[  103.850331]        nl80211_disconnect+0x6e/0xb0 [cfg80211]
[  103.850422]        genl_family_rcv_msg_doit+0xcd/0x110
[  103.850430]        genl_rcv_msg+0xce/0x1c0
[  103.850435]        netlink_rcv_skb+0x50/0xf0
[  103.850441]        genl_rcv+0x24/0x40
[  103.850446]        netlink_unicast+0x16d/0x230
[  103.850452]        netlink_sendmsg+0x22b/0x450
[  103.850457]        sock_sendmsg+0x5e/0x60
[  103.850465]        ____sys_sendmsg+0x22f/0x270
[  103.850472]        ___sys_sendmsg+0x81/0xc0
[  103.850479]        __sys_sendmsg+0x49/0x80
[  103.850485]        do_syscall_64+0x3b/0x90
[  103.850493]        entry_SYSCALL_64_after_hwframe+0x44/0xae
[  103.850500]
               other info that might help us debug this:

[  103.850504]  Possible unsafe locking scenario:

[  103.850507]        CPU0                    CPU1
[  103.850510]        ----                    ----
[  103.850512]   lock(&pstapriv->sta_hash_lock);
[  103.850518]                                lock(&pxmitpriv->lock);
[  103.850524]                                lock(&pstapriv->sta_hash_lock);
[  103.850530]   lock(&pxmitpriv->lock);
[  103.850535]
                *** DEADLOCK ***

Push the taking of sta_hash_lock down into rtw_free_stainfo(),
where the critical section is, this allows taking the lock after
rtw_free_stainfo() has released pxmitpriv->lock.

This requires changing rtw_free_all_stainfo() so that it does its freeing
in 2 steps, first moving all stainfo-s to free to a local list while
holding the sta_hash_lock and then walking that list to call
rtw_free_stainfo() on them without holding the sta_hash_lock.

Pushing the taking of sta_hash_lock down into rtw_free_stainfo(),
also fixes a whole bunch of callers of rtw_free_stainfo() which
were not holding that lock even though they should.

Note that this also fixes the deadlock from the "remove possible
deadlock when disconnect" patch in a different way. But the
changes from that patch offer a nice locking cleanup regardless.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210920145502.155454-2-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Nov 25, 2021
[ Upstream commit bdc1bbd ]

The assoc_timer takes the pmlmepriv->lock and various functions which
take the pmlmepriv->scanned_queue.lock first take the pmlmepriv->lock,
this means that we cannot have code which waits for the timer
(timer_del_sync) while holding the pmlmepriv->scanned_queue.lock
to avoid a triangle deadlock:

[  363.139361] ======================================================
[  363.139377] WARNING: possible circular locking dependency detected
[  363.139396] 5.15.0-rc1+ torvalds#470 Tainted: G         C  E
[  363.139413] ------------------------------------------------------
[  363.139424] RTW_CMD_THREAD/2466 is trying to acquire lock:
[  363.139441] ffffbacd00699038 (&pmlmepriv->lock){+.-.}-{2:2}, at: _rtw_join_timeout_handler+0x3c/0x160 [r8723bs]
[  363.139598]
               but task is already holding lock:
[  363.139610] ffffbacd00128ea0 ((&pmlmepriv->assoc_timer)){+.-.}-{0:0}, at: call_timer_fn+0x5/0x260
[  363.139673]
               which lock already depends on the new lock.

[  363.139684]
               the existing dependency chain (in reverse order) is:
[  363.139696]
               -> #2 ((&pmlmepriv->assoc_timer)){+.-.}-{0:0}:
[  363.139734]        del_timer_sync+0x59/0x100
[  363.139762]        rtw_joinbss_event_prehandle+0x342/0x640 [r8723bs]
[  363.139870]        report_join_res+0xdf/0x110 [r8723bs]
[  363.139980]        OnAssocRsp+0x17a/0x200 [r8723bs]
[  363.140092]        rtw_recv_entry+0x190/0x1120 [r8723bs]
[  363.140209]        rtl8723b_process_phy_info+0x3f9/0x750 [r8723bs]
[  363.140318]        tasklet_action_common.constprop.0+0xe8/0x110
[  363.140345]        __do_softirq+0xde/0x485
[  363.140372]        __irq_exit_rcu+0xd0/0x100
[  363.140393]        irq_exit_rcu+0xa/0x20
[  363.140413]        common_interrupt+0x83/0xa0
[  363.140440]        asm_common_interrupt+0x1e/0x40
[  363.140463]        finish_task_switch.isra.0+0x157/0x3d0
[  363.140492]        __schedule+0x447/0x1880
[  363.140516]        schedule+0x59/0xc0
[  363.140537]        smpboot_thread_fn+0x161/0x1c0
[  363.140565]        kthread+0x143/0x160
[  363.140585]        ret_from_fork+0x22/0x30
[  363.140614]
               -> #1 (&pmlmepriv->scanned_queue.lock){+.-.}-{2:2}:
[  363.140653]        _raw_spin_lock_bh+0x34/0x40
[  363.140675]        rtw_free_network_queue+0x31/0x80 [r8723bs]
[  363.140776]        rtw_sitesurvey_cmd+0x79/0x1e0 [r8723bs]
[  363.140869]        rtw_cfg80211_surveydone_event_callback+0x3cf/0x470 [r8723bs]
[  363.140973]        rdev_scan+0x42/0x1a0 [cfg80211]
[  363.141307]        nl80211_trigger_scan+0x566/0x660 [cfg80211]
[  363.141635]        genl_family_rcv_msg_doit+0xcd/0x110
[  363.141661]        genl_rcv_msg+0xce/0x1c0
[  363.141680]        netlink_rcv_skb+0x50/0xf0
[  363.141699]        genl_rcv+0x24/0x40
[  363.141717]        netlink_unicast+0x16d/0x230
[  363.141736]        netlink_sendmsg+0x22b/0x450
[  363.141755]        sock_sendmsg+0x5e/0x60
[  363.141781]        ____sys_sendmsg+0x22f/0x270
[  363.141803]        ___sys_sendmsg+0x81/0xc0
[  363.141828]        __sys_sendmsg+0x49/0x80
[  363.141851]        do_syscall_64+0x3b/0x90
[  363.141873]        entry_SYSCALL_64_after_hwframe+0x44/0xae
[  363.141895]
               -> #0 (&pmlmepriv->lock){+.-.}-{2:2}:
[  363.141930]        __lock_acquire+0x1158/0x1de0
[  363.141954]        lock_acquire+0xb5/0x2b0
[  363.141974]        _raw_spin_lock_bh+0x34/0x40
[  363.141993]        _rtw_join_timeout_handler+0x3c/0x160 [r8723bs]
[  363.142097]        call_timer_fn+0x94/0x260
[  363.142122]        __run_timers.part.0+0x1bf/0x290
[  363.142147]        run_timer_softirq+0x26/0x50
[  363.142171]        __do_softirq+0xde/0x485
[  363.142193]        __irq_exit_rcu+0xd0/0x100
[  363.142215]        irq_exit_rcu+0xa/0x20
[  363.142235]        sysvec_apic_timer_interrupt+0x72/0x90
[  363.142260]        asm_sysvec_apic_timer_interrupt+0x12/0x20
[  363.142283]        __module_address.part.0+0x0/0xd0
[  363.142309]        is_module_address+0x25/0x40
[  363.142334]        static_obj+0x4f/0x60
[  363.142361]        lockdep_init_map_type+0x47/0x220
[  363.142382]        __init_swait_queue_head+0x45/0x60
[  363.142408]        mmc_wait_for_req+0x4a/0xc0 [mmc_core]
[  363.142504]        mmc_wait_for_cmd+0x55/0x70 [mmc_core]
[  363.142592]        mmc_io_rw_direct+0x75/0xe0 [mmc_core]
[  363.142691]        sdio_writeb+0x2e/0x50 [mmc_core]
[  363.142788]        _sd_cmd52_write+0x62/0x80 [r8723bs]
[  363.142885]        sd_cmd52_write+0x6c/0xb0 [r8723bs]
[  363.142981]        rtl8723bs_set_hal_ops+0x982/0x9b0 [r8723bs]
[  363.143089]        rtw_write16+0x1e/0x30 [r8723bs]
[  363.143184]        SetHwReg8723B+0xcc9/0xd30 [r8723bs]
[  363.143294]        mlmeext_joinbss_event_callback+0x17a/0x1a0 [r8723bs]
[  363.143405]        rtw_joinbss_event_callback+0x11/0x20 [r8723bs]
[  363.143507]        mlme_evt_hdl+0x4d/0x70 [r8723bs]
[  363.143620]        rtw_cmd_thread+0x168/0x3c0 [r8723bs]
[  363.143712]        kthread+0x143/0x160
[  363.143732]        ret_from_fork+0x22/0x30
[  363.143757]
               other info that might help us debug this:

[  363.143768] Chain exists of:
                 &pmlmepriv->lock --> &pmlmepriv->scanned_queue.lock --> (&pmlmepriv->assoc_timer)

[  363.143809]  Possible unsafe locking scenario:

[  363.143819]        CPU0                    CPU1
[  363.143831]        ----                    ----
[  363.143841]   lock((&pmlmepriv->assoc_timer));
[  363.143862]                                lock(&pmlmepriv->scanned_queue.lock);
[  363.143882]                                lock((&pmlmepriv->assoc_timer));
[  363.143902]   lock(&pmlmepriv->lock);
[  363.143921]
                *** DEADLOCK ***

Make rtw_joinbss_event_prehandle() release the scanned_queue.lock before
it deletes the timer to avoid this (it is still holding pmlmepriv->lock
protecting against racing the timer).

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210920145502.155454-3-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Nov 25, 2021
[ Upstream commit a7ac783 ]

Lockdep complains about rtw_free_assoc_resources() taking the sta_hash_lock
followed by it calling rtw_free_stainfo() which takes xmitpriv->lock.
While the rtl8723bs_xmit_thread takes the sta_hash_lock while already
holding the xmitpriv->lock:

[  103.849756] ======================================================
[  103.849761] WARNING: possible circular locking dependency detected
[  103.849767] 5.15.0-rc1+ torvalds#470 Tainted: G         C  E
[  103.849773] ------------------------------------------------------
[  103.849776] wpa_supplicant/695 is trying to acquire lock:
[  103.849781] ffffa5d0c0562b00 (&pxmitpriv->lock){+.-.}-{2:2}, at: rtw_free_stainfo+0x8a/0x510 [r8723bs]
[  103.849840]
               but task is already holding lock:
[  103.849843] ffffa5d0c05636a8 (&pstapriv->sta_hash_lock){+.-.}-{2:2}, at: rtw_free_assoc_resources+0x48/0x110 [r8723bs]
[  103.849881]
               which lock already depends on the new lock.

[  103.849884]
               the existing dependency chain (in reverse order) is:
[  103.849887]
               -> #1 (&pstapriv->sta_hash_lock){+.-.}-{2:2}:
[  103.849898]        _raw_spin_lock_bh+0x34/0x40
[  103.849913]        rtw_get_stainfo+0x93/0x110 [r8723bs]
[  103.849948]        rtw_make_wlanhdr+0x14a/0x270 [r8723bs]
[  103.849983]        rtw_xmitframe_coalesce+0x5c/0x6c0 [r8723bs]
[  103.850019]        rtl8723bs_xmit_thread+0x4ac/0x620 [r8723bs]
[  103.850050]        kthread+0x143/0x160
[  103.850058]        ret_from_fork+0x22/0x30
[  103.850067]
               -> #0 (&pxmitpriv->lock){+.-.}-{2:2}:
[  103.850077]        __lock_acquire+0x1158/0x1de0
[  103.850084]        lock_acquire+0xb5/0x2b0
[  103.850090]        _raw_spin_lock_bh+0x34/0x40
[  103.850095]        rtw_free_stainfo+0x8a/0x510 [r8723bs]
[  103.850130]        rtw_free_assoc_resources+0x53/0x110 [r8723bs]
[  103.850159]        PHY_IQCalibrate_8723B+0x122b/0x36a0 [r8723bs]
[  103.850189]        cfg80211_disconnect+0x173/0x320 [cfg80211]
[  103.850331]        nl80211_disconnect+0x6e/0xb0 [cfg80211]
[  103.850422]        genl_family_rcv_msg_doit+0xcd/0x110
[  103.850430]        genl_rcv_msg+0xce/0x1c0
[  103.850435]        netlink_rcv_skb+0x50/0xf0
[  103.850441]        genl_rcv+0x24/0x40
[  103.850446]        netlink_unicast+0x16d/0x230
[  103.850452]        netlink_sendmsg+0x22b/0x450
[  103.850457]        sock_sendmsg+0x5e/0x60
[  103.850465]        ____sys_sendmsg+0x22f/0x270
[  103.850472]        ___sys_sendmsg+0x81/0xc0
[  103.850479]        __sys_sendmsg+0x49/0x80
[  103.850485]        do_syscall_64+0x3b/0x90
[  103.850493]        entry_SYSCALL_64_after_hwframe+0x44/0xae
[  103.850500]
               other info that might help us debug this:

[  103.850504]  Possible unsafe locking scenario:

[  103.850507]        CPU0                    CPU1
[  103.850510]        ----                    ----
[  103.850512]   lock(&pstapriv->sta_hash_lock);
[  103.850518]                                lock(&pxmitpriv->lock);
[  103.850524]                                lock(&pstapriv->sta_hash_lock);
[  103.850530]   lock(&pxmitpriv->lock);
[  103.850535]
                *** DEADLOCK ***

Push the taking of sta_hash_lock down into rtw_free_stainfo(),
where the critical section is, this allows taking the lock after
rtw_free_stainfo() has released pxmitpriv->lock.

This requires changing rtw_free_all_stainfo() so that it does its freeing
in 2 steps, first moving all stainfo-s to free to a local list while
holding the sta_hash_lock and then walking that list to call
rtw_free_stainfo() on them without holding the sta_hash_lock.

Pushing the taking of sta_hash_lock down into rtw_free_stainfo(),
also fixes a whole bunch of callers of rtw_free_stainfo() which
were not holding that lock even though they should.

Note that this also fixes the deadlock from the "remove possible
deadlock when disconnect" patch in a different way. But the
changes from that patch offer a nice locking cleanup regardless.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210920145502.155454-2-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Nov 25, 2021
[ Upstream commit bdc1bbd ]

The assoc_timer takes the pmlmepriv->lock and various functions which
take the pmlmepriv->scanned_queue.lock first take the pmlmepriv->lock,
this means that we cannot have code which waits for the timer
(timer_del_sync) while holding the pmlmepriv->scanned_queue.lock
to avoid a triangle deadlock:

[  363.139361] ======================================================
[  363.139377] WARNING: possible circular locking dependency detected
[  363.139396] 5.15.0-rc1+ torvalds#470 Tainted: G         C  E
[  363.139413] ------------------------------------------------------
[  363.139424] RTW_CMD_THREAD/2466 is trying to acquire lock:
[  363.139441] ffffbacd00699038 (&pmlmepriv->lock){+.-.}-{2:2}, at: _rtw_join_timeout_handler+0x3c/0x160 [r8723bs]
[  363.139598]
               but task is already holding lock:
[  363.139610] ffffbacd00128ea0 ((&pmlmepriv->assoc_timer)){+.-.}-{0:0}, at: call_timer_fn+0x5/0x260
[  363.139673]
               which lock already depends on the new lock.

[  363.139684]
               the existing dependency chain (in reverse order) is:
[  363.139696]
               -> #2 ((&pmlmepriv->assoc_timer)){+.-.}-{0:0}:
[  363.139734]        del_timer_sync+0x59/0x100
[  363.139762]        rtw_joinbss_event_prehandle+0x342/0x640 [r8723bs]
[  363.139870]        report_join_res+0xdf/0x110 [r8723bs]
[  363.139980]        OnAssocRsp+0x17a/0x200 [r8723bs]
[  363.140092]        rtw_recv_entry+0x190/0x1120 [r8723bs]
[  363.140209]        rtl8723b_process_phy_info+0x3f9/0x750 [r8723bs]
[  363.140318]        tasklet_action_common.constprop.0+0xe8/0x110
[  363.140345]        __do_softirq+0xde/0x485
[  363.140372]        __irq_exit_rcu+0xd0/0x100
[  363.140393]        irq_exit_rcu+0xa/0x20
[  363.140413]        common_interrupt+0x83/0xa0
[  363.140440]        asm_common_interrupt+0x1e/0x40
[  363.140463]        finish_task_switch.isra.0+0x157/0x3d0
[  363.140492]        __schedule+0x447/0x1880
[  363.140516]        schedule+0x59/0xc0
[  363.140537]        smpboot_thread_fn+0x161/0x1c0
[  363.140565]        kthread+0x143/0x160
[  363.140585]        ret_from_fork+0x22/0x30
[  363.140614]
               -> #1 (&pmlmepriv->scanned_queue.lock){+.-.}-{2:2}:
[  363.140653]        _raw_spin_lock_bh+0x34/0x40
[  363.140675]        rtw_free_network_queue+0x31/0x80 [r8723bs]
[  363.140776]        rtw_sitesurvey_cmd+0x79/0x1e0 [r8723bs]
[  363.140869]        rtw_cfg80211_surveydone_event_callback+0x3cf/0x470 [r8723bs]
[  363.140973]        rdev_scan+0x42/0x1a0 [cfg80211]
[  363.141307]        nl80211_trigger_scan+0x566/0x660 [cfg80211]
[  363.141635]        genl_family_rcv_msg_doit+0xcd/0x110
[  363.141661]        genl_rcv_msg+0xce/0x1c0
[  363.141680]        netlink_rcv_skb+0x50/0xf0
[  363.141699]        genl_rcv+0x24/0x40
[  363.141717]        netlink_unicast+0x16d/0x230
[  363.141736]        netlink_sendmsg+0x22b/0x450
[  363.141755]        sock_sendmsg+0x5e/0x60
[  363.141781]        ____sys_sendmsg+0x22f/0x270
[  363.141803]        ___sys_sendmsg+0x81/0xc0
[  363.141828]        __sys_sendmsg+0x49/0x80
[  363.141851]        do_syscall_64+0x3b/0x90
[  363.141873]        entry_SYSCALL_64_after_hwframe+0x44/0xae
[  363.141895]
               -> #0 (&pmlmepriv->lock){+.-.}-{2:2}:
[  363.141930]        __lock_acquire+0x1158/0x1de0
[  363.141954]        lock_acquire+0xb5/0x2b0
[  363.141974]        _raw_spin_lock_bh+0x34/0x40
[  363.141993]        _rtw_join_timeout_handler+0x3c/0x160 [r8723bs]
[  363.142097]        call_timer_fn+0x94/0x260
[  363.142122]        __run_timers.part.0+0x1bf/0x290
[  363.142147]        run_timer_softirq+0x26/0x50
[  363.142171]        __do_softirq+0xde/0x485
[  363.142193]        __irq_exit_rcu+0xd0/0x100
[  363.142215]        irq_exit_rcu+0xa/0x20
[  363.142235]        sysvec_apic_timer_interrupt+0x72/0x90
[  363.142260]        asm_sysvec_apic_timer_interrupt+0x12/0x20
[  363.142283]        __module_address.part.0+0x0/0xd0
[  363.142309]        is_module_address+0x25/0x40
[  363.142334]        static_obj+0x4f/0x60
[  363.142361]        lockdep_init_map_type+0x47/0x220
[  363.142382]        __init_swait_queue_head+0x45/0x60
[  363.142408]        mmc_wait_for_req+0x4a/0xc0 [mmc_core]
[  363.142504]        mmc_wait_for_cmd+0x55/0x70 [mmc_core]
[  363.142592]        mmc_io_rw_direct+0x75/0xe0 [mmc_core]
[  363.142691]        sdio_writeb+0x2e/0x50 [mmc_core]
[  363.142788]        _sd_cmd52_write+0x62/0x80 [r8723bs]
[  363.142885]        sd_cmd52_write+0x6c/0xb0 [r8723bs]
[  363.142981]        rtl8723bs_set_hal_ops+0x982/0x9b0 [r8723bs]
[  363.143089]        rtw_write16+0x1e/0x30 [r8723bs]
[  363.143184]        SetHwReg8723B+0xcc9/0xd30 [r8723bs]
[  363.143294]        mlmeext_joinbss_event_callback+0x17a/0x1a0 [r8723bs]
[  363.143405]        rtw_joinbss_event_callback+0x11/0x20 [r8723bs]
[  363.143507]        mlme_evt_hdl+0x4d/0x70 [r8723bs]
[  363.143620]        rtw_cmd_thread+0x168/0x3c0 [r8723bs]
[  363.143712]        kthread+0x143/0x160
[  363.143732]        ret_from_fork+0x22/0x30
[  363.143757]
               other info that might help us debug this:

[  363.143768] Chain exists of:
                 &pmlmepriv->lock --> &pmlmepriv->scanned_queue.lock --> (&pmlmepriv->assoc_timer)

[  363.143809]  Possible unsafe locking scenario:

[  363.143819]        CPU0                    CPU1
[  363.143831]        ----                    ----
[  363.143841]   lock((&pmlmepriv->assoc_timer));
[  363.143862]                                lock(&pmlmepriv->scanned_queue.lock);
[  363.143882]                                lock((&pmlmepriv->assoc_timer));
[  363.143902]   lock(&pmlmepriv->lock);
[  363.143921]
                *** DEADLOCK ***

Make rtw_joinbss_event_prehandle() release the scanned_queue.lock before
it deletes the timer to avoid this (it is still holding pmlmepriv->lock
protecting against racing the timer).

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210920145502.155454-3-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
mj22226 pushed a commit to mj22226/linux that referenced this pull request Oct 31, 2022
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000080
Internal error: Oops: 96000005 [#1] PREEMPT SMP
Modules linked in: bcmdhd dhd_static_buf r8168
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.110 torvalds#470
Hardware name: Rockchip RK3588 EVB1 LP4 V10 Board (DT)
pstate: 20400009 (nzCv daif +PAN -UAO -TCO BTYPE=--)
pc : dmaengine_pcm_dma_complete+0x44/0xdc
lr : pl330_tasklet+0xd4/0x2d0
sp : ffffffc01249bdf0
x29: ffffffc01249bdf0 x28: 0000000000000000
x27: ffffff8102c8c608 x26: 0000000000000002
x25: ffffff8102c8c608 x24: ffffff8102d4c600
x23: ffffff81018868c0 x22: ffffff8102c8c618
x21: 0000000000000000 x20: ffffffc010f238ec
x19: ffffff8102c8c560 x18: ffffffc012491048
x17: 0000000000000000 x16: 0000000000000000
x15: 0000000000000000 x14: 000000000007fcc4
x13: 0000000000000004 x12: 0000000a7e22d2ff
x11: 0000000000004007 x10: 0000000000000000
x9 : 0000000000003000 x8 : ffffff8030b7d480
x7 : 000000b2b5593519 x6 : 00000000003033ff
x5 : 0000000000000000 x4 : 0000000000bb82b6
x3 : ffffff8102c90b28 x2 : 0000000000000001
x1 : 0000000000000000 x0 : ffffff8102d4c600
Call trace:
 dmaengine_pcm_dma_complete+0x44/0xdc
 pl330_tasklet+0xd4/0x2d0
 tasklet_action_common+0x11c/0x414
 tasklet_action+0x28/0x38
 _stext+0x108/0x408
 __irq_exit_rcu+0xc0/0xc4
 irq_exit+0x14/0x28
 __handle_domain_irq+0x84/0xd0
 gic_handle_irq+0x78/0x154
 el1_irq+0xe4/0x1c0
 cpuidle_enter_state+0x200/0x3b8
 cpuidle_enter+0x3c/0x58
 cpuidle_idle_call+0x158/0x238
 do_idle+0xac/0xfc
 cpu_startup_entry+0x28/0x2c
 rest_init+0xd8/0xec
 arch_call_rest_init+0x14/0x24
 start_kernel+0x3d8/0x500

Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
Change-Id: Ib3d3ac842d3cd249c8cc6f516178031400dbc307
akiernan pushed a commit to zuma-array/linux that referenced this pull request Nov 3, 2022
PD#150081: driver defect clean up:
torvalds#20
torvalds#38
torvalds#87
torvalds#468
torvalds#469
torvalds#470
torvalds#471
torvalds#613
torvalds#668
  

Change-Id: Ifa0756e25088599571761b33efaffb6c2c898dfc
Signed-off-by: Evoke Zhang <evoke.zhang@amlogic.com>
akiernan pushed a commit to zuma-array/linux that referenced this pull request Nov 4, 2022
PD#150081: driver defect clean up:
torvalds#20
torvalds#38
torvalds#87
torvalds#468
torvalds#469
torvalds#470
torvalds#471
torvalds#613
torvalds#668
  

Change-Id: Ifa0756e25088599571761b33efaffb6c2c898dfc
Signed-off-by: Evoke Zhang <evoke.zhang@amlogic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants