Revert "Code of Conduct: Let's revamp it." #593

zhenhuaw-me · 2018-09-19T10:07:40Z

This reverts commit 8a104f8.

Code is just code, no politics please.

This reverts commit 8a104f8. Code is just code, no politics please.

The Code of Conflict is not achieving its implicit goal of fostering civility and the spirit of 'be excellent to each other'. Explicit guidelines have demonstrated success in other projects and other areas of the kernel. Here is a Code of Conduct statement for the wider kernel. It is based on the Contributor Covenant as described at www.contributor-covenant.org From this point forward, we should abide by these rules in order to help make the kernel community a welcoming environment to participate in. Signed-off-by: Chris Mason <clm@fb.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Olof Johansson <olof@lxom.net> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

KernelPRBot · 2018-09-19T10:09:36Z

Hi @jackwish!

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.
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 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

Working with the kernel development community - the official documentation for new kernel contributors

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.

jmarcher · 2018-09-19T13:34:56Z

Why do people want to "hack" the kernel, this kind of PR are not any good.
And by the way, you need to read that this repository is READ ONLY

zhenhuaw-me · 2018-09-19T13:46:32Z

Why do people want to "hack" the kernel, this kind of PR are not any good.
And by the way, you need to read that this repository is READ ONLY

@jmarcher thanks for your reminder. This is not any hack, only to complain the newly introduced CoC of linux kernel. :)

zhenhuaw-me · 2018-09-19T13:48:19Z

To the CoC of linux kernel (with respect to the community however).

jmarcher · 2018-09-19T14:13:40Z

If you were more cognate to the Linux community and you would understand what I meant with "hack" but anyways...

zhenhuaw-me · 2018-09-19T15:21:26Z

If you were more cognate to the Linux community and you would understand what I meant with "hack" but anyways...

@jmarcher Ok then... I have only worked on kernel for about half year when i was at school :) Would you please address the hack in the community? really curious...

ghost · 2018-09-20T09:32:19Z

+1

644 · 2018-09-20T09:38:00Z

+1 I wish people would stop bringing politics into technology

Tsoukaladelis · 2018-09-20T09:53:59Z

+1

watkinsr · 2018-09-20T10:45:54Z

+1

420git · 2018-09-20T10:48:52Z

+1

dodona2 · 2018-09-20T11:26:05Z

I clearly support jackwish. Remove politics out of the kernel, and all other software projects!
Revert !!!

fs-c · 2018-09-20T11:46:07Z

Use the proper channels for contributions/discussion -- GitHub is not one of them.

VincentW2 · 2018-09-20T12:08:01Z

+1

rockisch · 2018-09-20T12:34:45Z

+1
While I agree that the the linux project could have some kind of code of conduct, in the end this is Linus's project, and he should be the one defining it. The current CoC DEFINITELY doesn't match with Linus's ideals, and it was only merged into the code due to pressure of some specific individuals.

rockisch · 2018-09-20T16:12:12Z

@asm-pas I don't see what other contributes have to do with my comment. I'm not saying that I agree with the new code of conduct. I've read it, and I believe it is pure trash. I'm just saying that if the project wants a COC, it should be written by Linus, probably having only basic stuff, and then the community could modify it slowly, with discussions on what should enter and what shouldn't.

FelixWolf · 2018-09-20T16:25:19Z

+1
I highly oppose the new code of conduct based off the "Contributor Covenant". It has been used to "ban" people from contributions if their behaviour unrelated to the project is deemed "wrong" or if their personal ideologies are seen as "incorrect".
There was nothing wrong with the original code of conduct. It was straight to the point and avoided politics. This one introduces politics and was originally(the contributor covenant) made so people(who may or may not even contribute) can enforce stuff like opal/opal#941 and kick out great and active contributors off a project because someone disagrees with their personal ideals, regardless if they are not representing the project when stating those ideals.
Code should remain politics free and we as developers should only be concerned with how good is the code, not who wrote the code.
The new code of conduct is a very dangerous change and should be reverted.

I may not be a contributor to linux, but I use it and write code and programs that work on linux. I develop for linux before I develop for anything else, I use it "religiously" and have actively encouraged use of it. Seeing the kernel open a gate to allow people to censor people's views or kick them out if they refuse pains me deeply and has me very concerned for the future of linux.

dodona2 · 2018-09-20T17:24:46Z

+1
I highly oppose the new code of conduct based off the "Contributor Covenant". It has been used to "ban" people from contributions if their behaviour unrelated to the project is deemed "wrong" or if their personal ideologies are seen as "incorrect".

people who aren't smart enough to code will censor smart peoples work and will become a 'important' not to say a leading part or even the speakers of the project. Bad code of politically subjugated people will replace excellent code of smart programmers. We had that already in the name of 'good', 'justice' and 'progress' in totalitarian dictatorships beginning with the soviet union.

nottux · 2018-09-20T17:26:48Z

+1

SteveHeist · 2018-09-21T00:54:20Z

If it's impossible due to whatever reason just to scrap it wholesale, I've taken some time and rewrote the Code of Conduct in a manner that should prevent it's stark overreach, and allow for moderation towards the good of the kernel, rather than the good of other interests:

Code of Conduct Rewrite.txt

You're welcome to edit it (as should be obvious for an open source project), as I'm not certain I've covered every necessary base.

Gist for those who would rather look at it that way: https://gist.github.com/SteveHeist/ea4efb27ec8d474c68eb9831eec45491

OctonianCat · 2018-09-21T03:03:47Z

Programmers are not politicians. +1

kwanCCC · 2018-09-21T09:23:47Z

Programmers are not politicians. +1

jbruchon · 2018-09-21T11:50:59Z

The Code of Conduct is already being abused to try and remove prominent contributors.

Here's an archive link since Sarah/Sage Sharp block-bots people and may scramble to delete this tweet later.

Apparently we are supposed to blacklist @tytso because he's "a rape apologist" according to the totally not biased or full of crap source "Geek Feminism." The stupid, it burns.

420git · 2018-09-21T12:49:31Z

If it's impossible due to whatever reason just to scrap it wholesale, I've taken some time and rewrote the Code of Conduct in a manner that should prevent it's stark overreach, and allow for moderation towards the good of the kernel, rather than the good of other interests:

Code of Conduct Rewrite.txt

You're welcome to edit it (as should be obvious for an open source project), as I'm not certain I've covered every necessary base.

Gist for those who would rather look at it that way: https://gist.github.com/SteveHeist/ea4efb27ec8d474c68eb9831eec45491

Nice but you should include the LKML, as most discussions occur over there not on github. Also take the time to submit it thru proper channels. I see no reason why this code shouldnt be rewritten unless if there is a hidden agenda or pressure not to.

VincentW2 · 2018-09-21T12:58:09Z

The greatness about the old CoC is that it was simple. It valued quality of code over what you say. Nobody cared you were a transgender demi furry, if you contributed quality code, that's all that mattered.

tytso · 2018-09-21T14:52:39Z

For the record, I supported the CoC, and the reason why my Signed-off-by wasn't on the commit that landed in the git tree was due to my e-mail not getting read in time. So I am not in favor of the revert.

As far as Sage's attempt to label me, I think it's unfair, but I will let other people judge for themselves. It's also important to remember that accusations do not translate into an automatic presumption of guilt, and that many people in the Linux development community supported me and thought the claim was bogus the first time that old e-mail thread was exhumed several years ago.

Because my Signed-off-by got lost in e-mail, it meant I didn't get abuse from people screaming "SJW!" and "Anti-meritocracy!". So now I'm getting it from others who are diametrically opposed (opposed... opposed... sorry, just saw the musical Hamilton the other night :-). That's OK, I've been called worse before.

(For example, in my younger days when I thought I had to engage whenever I saw something wrong on the internet, and I got into a debate with some evangelical Christians about whether LGBT people were doomed to hell. I belong to a denomination that ordains gay bishops, so obviously for some that makes me a spawn of Satan....)

644 · 2018-09-21T15:25:59Z

@dodona2

+1
I highly oppose the new code of conduct based off the "Contributor Covenant". It has been used to "ban" people from contributions if their behaviour unrelated to the project is deemed "wrong" or if their personal ideologies are seen as "incorrect".

people who aren't smart enough to code will censor smart peoples work and will become a 'important' not to say a leading part or even the speakers of the project. Bad code of politically subjugated people will replace excellent code of smart programmers. We had that already in the name of 'good', 'justice' and 'progress' in totalitarian dictatorships beginning with the soviet union.

Smart people would realize when that's happening. A CoC isn't what I'd advise but a less despotical one could help set a middleground for those who want it and those who don't.

coffnix · 2018-09-21T16:38:50Z

+1

SteveHeist · 2018-10-03T18:30:06Z

Ah, I scrolled up and looked at where someone had linked Coraline's Twitter page and just ran with that name, although they both need to exit stage right at this point.

irufus · 2018-10-04T17:44:18Z

Power and oppression are not required for racism to exist. One can believe that racially-derived characteristics result in superiority or inferiority without any sort of power struggle being involved. The notion that racism requires some form of "power" over others in addition to harboring racist beliefs is a lie perpetrated by a book written almost four decades ago called "White Awareness" which explicitly said that its goal was to forcefully attempt to redefine the words used to discuss social issues to bake in desired ideological meanings.

Considering that the book was written during an era where the notion was obviously true your assessment that racism does not require some form of power is laughable.

jbruchon · 2018-10-04T18:24:05Z

@irufus No, it was not, and even if it was, racism can't be redefined to suit your political agenda. Sorry that hurts your feelings, but facts do not care about your feelings. Get over it.

mgbalant · 2018-10-04T18:54:08Z

In case my earlier message wasn't able to reach you. Cheers, Mark

…

-------- Forwarded Message -------- Subject: Re: [torvalds/linux] "Code of Conduct: Let's revamp it" (#593) Date: Thu, 4 Oct 2018 09:40:00 -0700 From: Mark Balançian <mbalant3@gmail.com> To: 42606649+SteveHeist@users.noreply.github.com I don't think anybody here is denying that Linus is a good person - it's just we're worried that Linus being Linus will get Linus removed from BDFL for "reasons" that are only vaguely & tangentially related to anything mentioned by the CoC and more to do with pressure to remove him on the entire LF-TAB. Yes. We're also worried about the "threat with teeth" that is people pulling their code citing GPL v2. That could downright disable any and all systems that run Linux when the kernel is updated. Threat with teeth? I thought GPL was v3 already as per on Github. Forgive my ignorance, feel free to explain. If Linus is truly your friend, tell him that this is going to go bad fast. This isn't somebody from the "underbelly of the Internet" saying that - it's a legitimate concern from a user that benefits from the project as it stands. Look at the prior instances of this being implemented and see how those went. Hell, if you think you need a new CoC because the Code of Conflict wasn't good enough, I WROTE ONE. It's above us in the thread, and works much better to implement clear and effective guidelines, in my mind, and has a dedicated "start date", meaning everyone involved gets to start clean about anything they did that doesn't work with the current CoC (or my CoC), and can fix their attitudes instead of being kicked out because of prior issues. @torvalds <https://github.com/torvalds> I beg of you, rethink this. It will go /horribly/. It may not kill Linux, and it won't kill mine because as we speak I'm backing up the kernel just so I have it on hand, but it has the potential to run off developers as they feel unwelcome. What's better, welcoming potential or keeping the known welcome? Where did the concept of "by developers, for developers" get twisted? Linus to me is moreso an acquaintance just yet. We hit it off at LinuxCon North America this year about penguins and stuff. But on to more important matters. Yes, he's already issued an email stating he's doing some sort of stepping aside stuff from the Linux Project? I could have this totally wrong as my reading comprehension on nights after work is crap. But I do recall him stating his requiring distance from the "morass of nastiness" the discussions surrounding the CoC have become. All I can extend is my sympathy. But in the end, that sympathy with respect to the LINUX PROJECT must extend to good code alone. Sorry. Furthermore, it might be important to note that despite Linus being good at heart, he's had gaps in interpersonal relativity which he's tried to bridge by being forceful and very direct (I myself have been guilty of that. Maybe that's why we get along) but he's seeking professional help regarding increasing his empathy toward others. Imagine! Stuff someone has to do nowadays! Anyways, anything that helps. I haven't read the iterations of the CoC yet but will when my work settles down and I can see if contributing a few says and lines here and there can mollify the disruption.

--Mark--

SteveHeist · 2018-10-04T19:30:25Z

My apologies Mark, I was not intending to ignore you, and I did miss your message.

I see you agree with at least the first sentence, which means I'm on the right mental track and haven't gone totally off the deep end.

As for the "threat with teeth" remark, I pulled it straight from the LKML itself, in this thread: https://lkml.org/lkml/2018/9/20/442

I had thought most people had already read that, so I didn't source it, my apologies.

I understand the sympathy limitations, and my worries extend to that point as well - I have the somewhat paranoid, somewhat warranted notion that the CoC could directly detriment the quality and availability of code to the Linux Kernel. If he needs to take a step back and rethink his attitude for the future, that's entirely welcome, and I applaud him for seeing that as an issue. However, I worry that there might not be much left to step back into if he walks away for too long at this rate.

I don't and didn't want to make this a political stink-war, I just wanted to say my piece and get my mind clear so I can go on with my day. I want to see the Linux Kernel strive and grow, and don't see this as a way to go about it. But, at the end of the day, I am no authority - and if Linus feels this new CoC will do better than the old Code of Conflict, who am I to judge?

Honestly, I'm at a point I've said everything I can think to say - I've had my soapbox and probably stood on it far too long in this regard. Best of luck with everything.

zhenhuaw-me · 2019-01-09T09:18:18Z

CoC is now everywhere, war ended. closing.

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 torvalds#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>

Further changes to comply with the ToS More ToS cleanup Bye bye George Melons Better to be safe than sorry

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 torvalds#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>

This commit fixes the following checkpatch.pl warnings: WARNING: do not add new typedefs torvalds#95: FILE: hal/odm.h:95: +typedef struct _Rate_Adaptive_Table_ { WARNING: do not add new typedefs torvalds#99: FILE: hal/odm.h:99: +typedef struct _RX_High_Power_ { WARNING: do not add new typedefs torvalds#129: FILE: hal/odm.h:129: +typedef struct _SW_Antenna_Switch_ { WARNING: do not add new typedefs torvalds#181: FILE: hal/odm.h:181: +typedef struct _ODM_RATE_ADAPTIVE { WARNING: do not add new typedefs torvalds#280: FILE: hal/odm.h:280: +typedef enum tag_Dynamic_ODM_Support_Ability_Type { WARNING: do not add new typedefs torvalds#300: FILE: hal/odm.h:300: +typedef struct _ODM_STA_INFO { WARNING: do not add new typedefs torvalds#328: FILE: hal/odm.h:328: +typedef enum _ODM_Common_Info_Definition { WARNING: do not add new typedefs torvalds#418: FILE: hal/odm.h:418: +typedef enum _ODM_Support_Ability_Definition { WARNING: do not add new typedefs torvalds#449: FILE: hal/odm.h:449: +typedef enum tag_ODM_Support_Interface_Definition { WARNING: do not add new typedefs torvalds#455: FILE: hal/odm.h:455: +typedef enum tag_ODM_Support_IC_Type_Definition { WARNING: do not add new typedefs torvalds#460: FILE: hal/odm.h:460: +typedef enum tag_ODM_Cut_Version_Definition { WARNING: do not add new typedefs torvalds#475: FILE: hal/odm.h:475: +typedef enum tag_ODM_Fab_Version_Definition { WARNING: do not add new typedefs torvalds#484: FILE: hal/odm.h:484: +typedef enum tag_ODM_RF_Path_Bit_Definition { WARNING: do not add new typedefs torvalds#495: FILE: hal/odm.h:495: +typedef enum tag_ODM_RF_Type_Definition { WARNING: do not add new typedefs torvalds#516: FILE: hal/odm.h:516: +typedef enum tag_ODM_MAC_PHY_Mode_Definition { WARNING: do not add new typedefs torvalds#522: FILE: hal/odm.h:522: +typedef enum tag_BT_Coexist_Definition { WARNING: do not add new typedefs torvalds#530: FILE: hal/odm.h:530: +typedef enum tag_Operation_Mode_Definition { WARNING: do not add new typedefs torvalds#543: FILE: hal/odm.h:543: +typedef enum tag_Wireless_Mode_Definition { WARNING: do not add new typedefs torvalds#555: FILE: hal/odm.h:555: +typedef enum tag_Band_Type_Definition { WARNING: do not add new typedefs torvalds#563: FILE: hal/odm.h:563: +typedef enum tag_Secondary_Channel_Offset_Definition { WARNING: do not add new typedefs torvalds#570: FILE: hal/odm.h:570: +typedef enum tag_Security_Definition { WARNING: do not add new typedefs torvalds#582: FILE: hal/odm.h:582: +typedef enum tag_Bandwidth_Definition { WARNING: do not add new typedefs torvalds#593: FILE: hal/odm.h:593: +typedef enum tag_Board_Definition { WARNING: do not add new typedefs torvalds#605: FILE: hal/odm.h:605: +typedef enum tag_ODM_Package_Definition { WARNING: do not add new typedefs torvalds#612: FILE: hal/odm.h:612: +typedef enum tag_ODM_TYPE_GPA_Definition { WARNING: do not add new typedefs torvalds#617: FILE: hal/odm.h:617: +typedef enum tag_ODM_TYPE_APA_Definition { WARNING: do not add new typedefs torvalds#622: FILE: hal/odm.h:622: +typedef enum tag_ODM_TYPE_GLNA_Definition { WARNING: do not add new typedefs torvalds#629: FILE: hal/odm.h:629: +typedef enum tag_ODM_TYPE_ALNA_Definition { WARNING: do not add new typedefs torvalds#637: FILE: hal/odm.h:637: +typedef enum tag_CCA_Path { WARNING: do not add new typedefs torvalds#643: FILE: hal/odm.h:643: +typedef struct _ODM_RA_Info_ { WARNING: do not add new typedefs torvalds#675: FILE: hal/odm.h:675: +typedef struct _IQK_MATRIX_REGS_SETTING { WARNING: do not add new typedefs torvalds#683: FILE: hal/odm.h:683: +typedef struct ODM_RF_Calibration_Structure { WARNING: do not add new typedefs #788: FILE: hal/odm.h:788: +typedef struct _FAST_ANTENNA_TRAINNING_ { WARNING: do not add new typedefs torvalds#828: FILE: hal/odm.h:828: +typedef enum _FAT_STATE { WARNING: do not add new typedefs torvalds#833: FILE: hal/odm.h:833: +typedef enum _ANT_DIV_TYPE { WARNING: do not add new typedefs torvalds#843: FILE: hal/odm.h:843: +typedef struct _ODM_PATH_DIVERSITY_ { WARNING: do not add new typedefs torvalds#852: FILE: hal/odm.h:852: +typedef enum _BASEBAND_CONFIG_PHY_REG_PG_VALUE_TYPE { WARNING: do not add new typedefs torvalds#860: FILE: hal/odm.h:860: +typedef struct _ANT_DETECTED_INFO { WARNING: do not add new typedefs torvalds#870: FILE: hal/odm.h:870: +typedef struct DM_Out_Source_Dynamic_Mechanism_Structure { WARNING: do not add new typedefs #1229: FILE: hal/odm.h:1229: + typedef enum _ODM_RF_CONTENT { WARNING: do not add new typedefs #1236: FILE: hal/odm.h:1236: +typedef enum _ODM_BB_Config_Type { WARNING: do not add new typedefs #1246: FILE: hal/odm.h:1246: +typedef enum _ODM_RF_Config_Type { WARNING: do not add new typedefs #1251: FILE: hal/odm.h:1251: +typedef enum _ODM_FW_Config_Type { WARNING: do not add new typedefs #1262: FILE: hal/odm.h:1262: +typedef enum _RT_STATUS { WARNING: do not add new typedefs #1319: FILE: hal/odm.h:1319: +typedef enum tag_1R_CCA_Type_Definition { WARNING: do not add new typedefs #1325: FILE: hal/odm.h:1325: +typedef enum tag_RF_Type_Definition { WARNING: do not add new typedefs #1334: FILE: hal/odm.h:1334: +typedef enum tag_SW_Antenna_Switch_Definition { Signed-off-by: Marco Cesati <marco.cesati@gmail.com>

This commit fixes the following checkpatch.pl warnings: WARNING: do not add new typedefs torvalds#95: FILE: hal/odm.h:95: +typedef struct _Rate_Adaptive_Table_ { WARNING: do not add new typedefs torvalds#99: FILE: hal/odm.h:99: +typedef struct _RX_High_Power_ { WARNING: do not add new typedefs torvalds#129: FILE: hal/odm.h:129: +typedef struct _SW_Antenna_Switch_ { WARNING: do not add new typedefs torvalds#181: FILE: hal/odm.h:181: +typedef struct _ODM_RATE_ADAPTIVE { WARNING: do not add new typedefs torvalds#280: FILE: hal/odm.h:280: +typedef enum tag_Dynamic_ODM_Support_Ability_Type { WARNING: do not add new typedefs torvalds#300: FILE: hal/odm.h:300: +typedef struct _ODM_STA_INFO { WARNING: do not add new typedefs torvalds#328: FILE: hal/odm.h:328: +typedef enum _ODM_Common_Info_Definition { WARNING: do not add new typedefs torvalds#418: FILE: hal/odm.h:418: +typedef enum _ODM_Support_Ability_Definition { WARNING: do not add new typedefs torvalds#449: FILE: hal/odm.h:449: +typedef enum tag_ODM_Support_Interface_Definition { WARNING: do not add new typedefs torvalds#455: FILE: hal/odm.h:455: +typedef enum tag_ODM_Support_IC_Type_Definition { WARNING: do not add new typedefs torvalds#460: FILE: hal/odm.h:460: +typedef enum tag_ODM_Cut_Version_Definition { WARNING: do not add new typedefs torvalds#475: FILE: hal/odm.h:475: +typedef enum tag_ODM_Fab_Version_Definition { WARNING: do not add new typedefs torvalds#484: FILE: hal/odm.h:484: +typedef enum tag_ODM_RF_Path_Bit_Definition { WARNING: do not add new typedefs torvalds#495: FILE: hal/odm.h:495: +typedef enum tag_ODM_RF_Type_Definition { WARNING: do not add new typedefs torvalds#516: FILE: hal/odm.h:516: +typedef enum tag_ODM_MAC_PHY_Mode_Definition { WARNING: do not add new typedefs torvalds#522: FILE: hal/odm.h:522: +typedef enum tag_BT_Coexist_Definition { WARNING: do not add new typedefs torvalds#530: FILE: hal/odm.h:530: +typedef enum tag_Operation_Mode_Definition { WARNING: do not add new typedefs torvalds#543: FILE: hal/odm.h:543: +typedef enum tag_Wireless_Mode_Definition { WARNING: do not add new typedefs torvalds#555: FILE: hal/odm.h:555: +typedef enum tag_Band_Type_Definition { WARNING: do not add new typedefs torvalds#563: FILE: hal/odm.h:563: +typedef enum tag_Secondary_Channel_Offset_Definition { WARNING: do not add new typedefs torvalds#570: FILE: hal/odm.h:570: +typedef enum tag_Security_Definition { WARNING: do not add new typedefs torvalds#582: FILE: hal/odm.h:582: +typedef enum tag_Bandwidth_Definition { WARNING: do not add new typedefs torvalds#593: FILE: hal/odm.h:593: +typedef enum tag_Board_Definition { WARNING: do not add new typedefs torvalds#605: FILE: hal/odm.h:605: +typedef enum tag_ODM_Package_Definition { WARNING: do not add new typedefs torvalds#612: FILE: hal/odm.h:612: +typedef enum tag_ODM_TYPE_GPA_Definition { WARNING: do not add new typedefs torvalds#617: FILE: hal/odm.h:617: +typedef enum tag_ODM_TYPE_APA_Definition { WARNING: do not add new typedefs torvalds#622: FILE: hal/odm.h:622: +typedef enum tag_ODM_TYPE_GLNA_Definition { WARNING: do not add new typedefs torvalds#629: FILE: hal/odm.h:629: +typedef enum tag_ODM_TYPE_ALNA_Definition { WARNING: do not add new typedefs torvalds#637: FILE: hal/odm.h:637: +typedef enum tag_CCA_Path { WARNING: do not add new typedefs torvalds#643: FILE: hal/odm.h:643: +typedef struct _ODM_RA_Info_ { WARNING: do not add new typedefs torvalds#675: FILE: hal/odm.h:675: +typedef struct _IQK_MATRIX_REGS_SETTING { WARNING: do not add new typedefs torvalds#683: FILE: hal/odm.h:683: +typedef struct ODM_RF_Calibration_Structure { WARNING: do not add new typedefs #788: FILE: hal/odm.h:788: +typedef struct _FAST_ANTENNA_TRAINNING_ { WARNING: do not add new typedefs torvalds#828: FILE: hal/odm.h:828: +typedef enum _FAT_STATE { WARNING: do not add new typedefs torvalds#833: FILE: hal/odm.h:833: +typedef enum _ANT_DIV_TYPE { WARNING: do not add new typedefs torvalds#843: FILE: hal/odm.h:843: +typedef struct _ODM_PATH_DIVERSITY_ { WARNING: do not add new typedefs torvalds#852: FILE: hal/odm.h:852: +typedef enum _BASEBAND_CONFIG_PHY_REG_PG_VALUE_TYPE { WARNING: do not add new typedefs torvalds#860: FILE: hal/odm.h:860: +typedef struct _ANT_DETECTED_INFO { WARNING: do not add new typedefs torvalds#870: FILE: hal/odm.h:870: +typedef struct DM_Out_Source_Dynamic_Mechanism_Structure { WARNING: do not add new typedefs #1229: FILE: hal/odm.h:1229: + typedef enum _ODM_RF_CONTENT { WARNING: do not add new typedefs #1236: FILE: hal/odm.h:1236: +typedef enum _ODM_BB_Config_Type { WARNING: do not add new typedefs #1246: FILE: hal/odm.h:1246: +typedef enum _ODM_RF_Config_Type { WARNING: do not add new typedefs #1251: FILE: hal/odm.h:1251: +typedef enum _ODM_FW_Config_Type { WARNING: do not add new typedefs #1262: FILE: hal/odm.h:1262: +typedef enum _RT_STATUS { WARNING: do not add new typedefs #1319: FILE: hal/odm.h:1319: +typedef enum tag_1R_CCA_Type_Definition { WARNING: do not add new typedefs #1325: FILE: hal/odm.h:1325: +typedef enum tag_RF_Type_Definition { WARNING: do not add new typedefs #1334: FILE: hal/odm.h:1334: +typedef enum tag_SW_Antenna_Switch_Definition { Signed-off-by: Marco Cesati <marco.cesati@gmail.com> Link: https://lore.kernel.org/r/20210312082638.25512-4-marco.cesati@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

…clk_bindings rust: add initial common clock framework bindings

nyabinary · 2024-06-27T11:12:28Z

lmao

Revert "Code of Conduct: Let's revamp it."

011eb0d

This reverts commit 8a104f8. Code is just code, no politics please.

zhenhuaw-me closed this Jan 9, 2019

AndrewSmart referenced this pull request in tgstation/tgstation Apr 17, 2020

Changes to comply with GitHub TOS

8dbf1cf

Further changes to comply with the ToS More ToS cleanup Bye bye George Melons Better to be safe than sorry

ojeda pushed a commit to ojeda/linux that referenced this pull request Jan 13, 2022

Merge pull request torvalds#593 from m-falkowski1/add_initial_common_…

c871b6d

…clk_bindings rust: add initial common clock framework bindings

Revert "Code of Conduct: Let's revamp it." #593

Revert "Code of Conduct: Let's revamp it." #593

Conversation

zhenhuaw-me commented Sep 19, 2018

KernelPRBot commented Sep 19, 2018

How do I format my contribution?

Who do I send my contribution to?

How do I send my contribution?

How do I get help if I'm stuck?

I sent my patch - now what?

Further information

jmarcher commented Sep 19, 2018

zhenhuaw-me commented Sep 19, 2018

zhenhuaw-me commented Sep 19, 2018

jmarcher commented Sep 19, 2018 • edited Loading

zhenhuaw-me commented Sep 19, 2018

ghost commented Sep 20, 2018

644 commented Sep 20, 2018

Tsoukaladelis commented Sep 20, 2018

watkinsr commented Sep 20, 2018

420git commented Sep 20, 2018

dodona2 commented Sep 20, 2018

fs-c commented Sep 20, 2018

VincentW2 commented Sep 20, 2018

rockisch commented Sep 20, 2018 • edited Loading

rockisch commented Sep 20, 2018

FelixWolf commented Sep 20, 2018 • edited Loading

dodona2 commented Sep 20, 2018 • edited Loading

nottux commented Sep 20, 2018

SteveHeist commented Sep 21, 2018 • edited Loading

OctonianCat commented Sep 21, 2018

kwanCCC commented Sep 21, 2018

jbruchon commented Sep 21, 2018 • edited Loading

420git commented Sep 21, 2018

VincentW2 commented Sep 21, 2018 via email • edited Loading

tytso commented Sep 21, 2018

644 commented Sep 21, 2018

coffnix commented Sep 21, 2018

SteveHeist commented Oct 3, 2018

irufus commented Oct 4, 2018 • edited Loading

jbruchon commented Oct 4, 2018

mgbalant commented Oct 4, 2018 via email

SteveHeist commented Oct 4, 2018

zhenhuaw-me commented Jan 9, 2019

nyabinary commented Jun 27, 2024

jmarcher commented Sep 19, 2018 •

edited

Loading

rockisch commented Sep 20, 2018 •

edited

Loading

FelixWolf commented Sep 20, 2018 •

edited

Loading

dodona2 commented Sep 20, 2018 •

edited

Loading

SteveHeist commented Sep 21, 2018 •

edited

Loading

jbruchon commented Sep 21, 2018 •

edited

Loading

VincentW2 commented Sep 21, 2018 via email •

edited

Loading

irufus commented Oct 4, 2018 •

edited

Loading