1. 25 Oct, 2016 6 commits
    • Charlie Jacobsen's avatar
      Except IPC, kliblcd fully tested. Everything is working. · 664628a4
      Charlie Jacobsen authored
      Documentation in Documentation/lcd-domains/...
      
      Loading, mapping, and running a module is working correctly, using
      all of the capability code that interposes on each operation (mapping,
      freeing pages, etc.).
      
      cptr allocation and indexing into cspaces is working correctly.
      
      IPC testing and debugging is coming next.
      664628a4
    • Charlie Jacobsen's avatar
      Muktesh's capabilities fully incorporated. Capsicum-style enter/exit. · 6ee9a51f
      Charlie Jacobsen authored
      Builds, but not fully tested. Good tests for capability subsystem, some tests
      for kliblcd.
      
      Non-isolated kernel threads can "enter" the lcd system by doing
      klcd_enter / klcd_exit. They can create other lcd's, set them up, etc. They
      use the same interface that regular lcd's will use, so such code could be
      moved to an lcd, as we had planned. Will document this in Documentation folder
      tomorrow ( == today ).
      
      Capability system does checks now when a capability is deleted/revoked: for
      example, if it's for a page, the microkernel checks if the page is mapped, and
      unmaps it. If the last capability goes away, the page is freed. Documentation
      is in Documentation/lcd-domains/cap.txt.
      
      IPC code is in place, but not tested yet (pray for me).
      
      Debug is taking some time. Sometimes requires a power cycle which adds an
      extra 5 - 10 minutes. Build is slow the first time after reboot. Give me a user
      level program and I'll debug it in 30 seconds! argc
      
      Main arch-independent files:
      
          include/lcd-domains/kliblcd.h, types.h
      
             This is what non-isolated kernel code should include to use the
             kliblcd interface to the microkernel.
      
          virt/lcd-domains/main.c, kliblcd.c, cap.c, ipc.c, internal.h
      
             The microkernel, broken up into pieces.
      
          virt/lcd-domains/tests/
      
             The tests, in progress.
      
      Some old files are still hanging around in virt/lcd-domains and will be
      incorprated/cleaned up soon.
      
      I couldn't squash over the merge from the decomposition branch, so there's a
      bunch of junk commits coming over. (I should've just copied Muktesh's files.)
      
      Conflicts:
      	drivers/Kconfig
      	drivers/lcd-cspace/test.h
      	include/lcd-domains/cap.h
      	include/lcd-prototype/lcd.h
      	include/lcd/console.h
      	include/lcd/elfnote.h
      	include/linux/init_task.h
      	include/linux/module.h
      	include/linux/sched.h
      	virt/lcd-domains/cap.c
      	virt/lcd-domains/ipc.c
      	virt/lcd-domains/lcd-cspace-tests2.c
      Resolved-by: Vikram Narayanan's avatarVikram Narayanan <vikram186@gmail.com>
      6ee9a51f
    • Charles Jacobsen's avatar
      Support for multiple threads in lcd (limited). Major clean up of code. · ded1cd32
      Charles Jacobsen authored
      In line with more recent design discussions, we now have (limited)
      support for running multiple threads inside an lcd.
      
      Each thread will have its own hardware vm, but share a guest
      physical address space and cspace.
      
      It's limited for now because threads cannot handle interrupts/exceptions
      internally in the lcd. This will require a per-thread TSS (much like
      Linux's per-core TSS/interrupt stack). I removed the gdt/idt/tss for
      now (Cf. with Dune, they don't use gdt/idt/tss) and will tackle that later
      after finishing more important stuff.
      
      I have only tested the code for running one hardware vm inside an lcd. Some
      code is missing proper locking for the future when we have multiple threads
      inside an lcd. I'm leaving this for now.
      
      The microkernel uses a simple bitmap for guest physical page allocation.
      
      Removed blob loading - code is set up for running modules exclusively.
      
      See the headers and Documentation/lcd-domains for more info.
      
      I put a flag at the top of files that are not currently in use, and will
      probably be deleted/incorporated later.
      ded1cd32
    • Charlie Jacobsen's avatar
      Simple ipc documentation. · 22f4bcd9
      Charlie Jacobsen authored
      22f4bcd9
    • Charlie Jacobsen's avatar
      Separated lcd into container and thread objects. · dbc4e40c
      Charlie Jacobsen authored
      Updated code. Removed gdt/tss/idt for now. Added doc directory
      and some initial doc.
      dbc4e40c
    • Muktesh Khole's avatar
      Adding Documentation for capability module · ad6d773f
      Muktesh Khole authored
      ad6d773f
  2. 16 Oct, 2016 1 commit
  3. 12 Sep, 2016 1 commit
    • Lee Jones's avatar
      dt-bindings: mmc: sdhci-st: Mention the discretionary "icn" clock · 981b1789
      Lee Jones authored
      The interconnect (ICN) clock is required for functional working of
      MMC on some ST platforms.  When not supplied it can result in
      broken MMC and the following output:
      
              [   13.916949] mmc0: Timeout waiting for hardware interrupt.
              [   13.922349] sdhci: =========== REGISTER DUMP (mmc0)===========
              [   13.928175] sdhci: Sys addr: 0x00000000 | Version:  0x00001002
              [   13.933999] sdhci: Blk size: 0x00007040 | Blk cnt:  0x00000001
              [   13.939825] sdhci: Argument: 0x00fffff0 | Trn mode: 0x00000013
              [   13.945650] sdhci: Present:  0x1fff0206 | Host ctl: 0x00000011
              [   13.951475] sdhci: Power:    0x0000000f | Blk gap:  0x00000080
              [   13.957300] sdhci: Wake-up:  0x00000000 | Clock:    0x00003f07
              [   13.963126] sdhci: Timeout:  0x00000004 | Int stat: 0x00000000
              [   13.968952] sdhci: Int enab: 0x02ff008b | Sig enab: 0x02ff008b
              [   13.974777] sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000
              [   13.980602] sdhci: Caps:     0x21ed3281 | Caps_1:   0x00000000
              [   13.986428] sdhci: Cmd:      0x0000063a | Max curr: 0x00000000
              [   13.992252] sdhci: Host ctl2: 0x00000000
              [   13.996166] sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x7c048200
              [   14.001990] sdhci: ===========================================
              [   14.009802] mmc0: Got data interrupt 0x02000000 even though no data operation was in progress.
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      981b1789
  4. 10 Sep, 2016 1 commit
    • Hans de Goede's avatar
      Input: silead_gsl1680 - document firmware-name, fix implementation · 43ba5883
      Hans de Goede authored
      The driver has supported touchscreen-fw-name to specify the firmware to
      load since it has been merged, but this was omitted from the dt-binding
      documentation.
      
      During review of adding touchscreen-fw-name to the binding documentation
      it was brought up that there is a standard property name called
      "firmware-name" for this, which should be used.
      
      Since there are no users of touchscreen-fw-name yet, this commit
      adds documentation of "firmware-name" to the dt-binding documentation
      and switches the driver over to use this.
      
      This commit also makes the driver add a "silead/" prefix to the
      firmware name from dt before calling request_firmware. That the
      firmware files are stored under /lib/firmware/silead under Linux
      is an implementation detail and does not belong in devicetree.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Acked-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      43ba5883
  5. 08 Sep, 2016 2 commits
  6. 01 Sep, 2016 3 commits
  7. 31 Aug, 2016 2 commits
  8. 28 Aug, 2016 2 commits
    • Florian Fainelli's avatar
      Documentation: networking: dsa: Remove platform device TODO · 7d13eca0
      Florian Fainelli authored
      Since commit 83c0afae ("net: dsa: Add new binding implementation"),
      the shortcomings of the dsa platform device have been addressed, remove
      that TODO item.
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Acked-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7d13eca0
    • Cyril Bur's avatar
      powerpc: signals: Discard transaction state from signal frames · 78a3e888
      Cyril Bur authored
      Userspace can begin and suspend a transaction within the signal
      handler which means they might enter sys_rt_sigreturn() with the
      processor in suspended state.
      
      sys_rt_sigreturn() wants to restore process context (which may have
      been in a transaction before signal delivery). To do this it must
      restore TM SPRS. To achieve this, any transaction initiated within the
      signal frame must be discarded in order to be able to restore TM SPRs
      as TM SPRs can only be manipulated non-transactionally..
      >From the PowerPC ISA:
        TM Bad Thing Exception [Category: Transactional Memory]
         An attempt is made to execute a mtspr targeting a TM register in
         other than Non-transactional state.
      
      Not doing so results in a TM Bad Thing:
      [12045.221359] Kernel BUG at c000000000050a40 [verbose debug info unavailable]
      [12045.221470] Unexpected TM Bad Thing exception at c000000000050a40 (msr 0x201033)
      [12045.221540] Oops: Unrecoverable exception, sig: 6 [#1]
      [12045.221586] SMP NR_CPUS=2048 NUMA PowerNV
      [12045.221634] Modules linked in: xt_CHECKSUM iptable_mangle ipt_MASQUERADE
       nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
       xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp bridge stp llc ebtable_filter
       ebtables ip6table_filter ip6_tables iptable_filter ip_tables x_tables kvm_hv kvm
       uio_pdrv_genirq ipmi_powernv uio powernv_rng ipmi_msghandler autofs4 ses enclosure
       scsi_transport_sas bnx2x ipr mdio libcrc32c
      [12045.222167] CPU: 68 PID: 6178 Comm: sigreturnpanic Not tainted 4.7.0 #34
      [12045.222224] task: c0000000fce38600 ti: c0000000fceb4000 task.ti: c0000000fceb4000
      [12045.222293] NIP: c000000000050a40 LR: c0000000000163bc CTR: 0000000000000000
      [12045.222361] REGS: c0000000fceb7ac0 TRAP: 0700   Not tainted (4.7.0)
      [12045.222418] MSR: 9000000300201033 <SF,HV,ME,IR,DR,RI,LE,TM[SE]> CR: 28444280  XER: 20000000
      [12045.222625] CFAR: c0000000000163b8 SOFTE: 0 PACATMSCRATCH: 900000014280f033
      GPR00: 01100000b8000001 c0000000fceb7d40 c00000000139c100 c0000000fce390d0
      GPR04: 900000034280f033 0000000000000000 0000000000000000 0000000000000000
      GPR08: 0000000000000000 b000000000001033 0000000000000001 0000000000000000
      GPR12: 0000000000000000 c000000002926400 0000000000000000 0000000000000000
      GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      GPR24: 0000000000000000 00003ffff98cadd0 00003ffff98cb470 0000000000000000
      GPR28: 900000034280f033 c0000000fceb7ea0 0000000000000001 c0000000fce390d0
      [12045.223535] NIP [c000000000050a40] tm_restore_sprs+0xc/0x1c
      [12045.223584] LR [c0000000000163bc] tm_recheckpoint+0x5c/0xa0
      [12045.223630] Call Trace:
      [12045.223655] [c0000000fceb7d80] [c000000000026e74] sys_rt_sigreturn+0x494/0x6c0
      [12045.223738] [c0000000fceb7e30] [c0000000000092e0] system_call+0x38/0x108
      [12045.223806] Instruction dump:
      [12045.223841] 7c800164 4e800020 7c0022a6 f80304a8 7c0222a6 f80304b0 7c0122a6 f80304b8
      [12045.223955] 4e800020 e80304a8 7c0023a6 e80304b0 <7c0223a6> e80304b8 7c0123a6 4e800020
      [12045.224074] ---[ end trace cb8002ee240bae76 ]---
      
      It isn't clear exactly if there is really a use case for userspace
      returning with a suspended transaction, however, doing so doesn't (on
      its own) constitute a bad frame. As such, this patch simply discards
      the transactional state of the context calling the sigreturn and
      continues.
      Reported-by: default avatarLaurent Dufour <ldufour@linux.vnet.ibm.com>
      Signed-off-by: default avatarCyril Bur <cyrilbur@gmail.com>
      Tested-by: default avatarLaurent Dufour <ldufour@linux.vnet.ibm.com>
      Reviewed-by: default avatarLaurent Dufour <ldufour@linux.vnet.ibm.com>
      Acked-by: default avatarSimon Guo <wei.guo.simon@gmail.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      78a3e888
  9. 23 Aug, 2016 1 commit
  10. 22 Aug, 2016 2 commits
  11. 19 Aug, 2016 1 commit
  12. 18 Aug, 2016 1 commit
  13. 17 Aug, 2016 2 commits
  14. 16 Aug, 2016 1 commit
    • Christoph Hellwig's avatar
      PCI: Use positive flags in pci_alloc_irq_vectors() · 4fe0d154
      Christoph Hellwig authored
      Instead of passing negative flags like PCI_IRQ_NOMSI to prevent use of
      certain interrupt types, pass positive flags like PCI_IRQ_LEGACY,
      PCI_IRQ_MSI, etc., to specify the acceptable interrupt types.
      
      This is based on a number of pending driver conversions that just happend
      to be a whole more obvious to read this way, and given that we have no
      users in the tree yet it can still easily be done.
      
      I've also added a PCI_IRQ_ALL_TYPES catchall to keep the case of accepting
      all interrupt types very simple.
      
      [bhelgaas: changelog, fix PCI_IRQ_AFFINITY doc typo, remove mention of
      PCI_IRQ_NOLEGACY]
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarAlexander Gordeev <agordeev@redhat.com>
      4fe0d154
  15. 14 Aug, 2016 1 commit
  16. 12 Aug, 2016 4 commits
  17. 11 Aug, 2016 1 commit
  18. 09 Aug, 2016 1 commit
    • Mathias Koehrer's avatar
      PCI: Update "pci=resource_alignment" documentation · 8b078c60
      Mathias Koehrer authored
      Some uio based PCI drivers, e.g., uio_cif, do not work if the assigned PCI
      memory resources are not page aligned.  By using the kernel option
      "pci=resource_alignment=<align>@<bus>:<slot>.<func>" it is possible to
      request page alignment for memory resources of devices.
      
      However, this is cumbersome when using several devices, and the
      bus/slot/func addresses may change if devices are added to or removed from
      the system.
      
      Extend the "pci=resource_alignment" option so we can specify the relevant
      devices via PCI vendor, device, subvendor, and subdevice IDs.  The
      specification of the devices via IDs is indicated by a leading string
      "pci:" as argument to "pci=resource_alignment".
      
      The format of the specification is
        pci:<vendor>:<device>[:<subvendor>:<subdevice>]
      
      Examples:
        pci=resource_alignment=4096@pci:8086:9c22:103c:198f
        pci=resource_alignment=pci:8086:9c22       # defaults to PAGE_SIZE align
      
      [bhelgaas: changelog, use actual vendor/device IDs in examples]
      Signed-off-by: default avatarMathias Koehrer <mathias.koehrer@etas.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      8b078c60
  19. 07 Aug, 2016 1 commit
    • Jens Axboe's avatar
      block: rename bio bi_rw to bi_opf · 1eff9d32
      Jens Axboe authored
      Since commit 63a4cc24, bio->bi_rw contains flags in the lower
      portion and the op code in the higher portions. This means that
      old code that relies on manually setting bi_rw is most likely
      going to be broken. Instead of letting that brokeness linger,
      rename the member, to force old and out-of-tree code to break
      at compile time instead of at runtime.
      
      No intended functional changes in this commit.
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      1eff9d32
  20. 05 Aug, 2016 2 commits
    • David Howells's avatar
      rxrpc: Fix races between skb free, ACK generation and replying · 372ee163
      David Howells authored
      Inside the kafs filesystem it is possible to occasionally have a call
      processed and terminated before we've had a chance to check whether we need
      to clean up the rx queue for that call because afs_send_simple_reply() ends
      the call when it is done, but this is done in a workqueue item that might
      happen to run to completion before afs_deliver_to_call() completes.
      
      Further, it is possible for rxrpc_kernel_send_data() to be called to send a
      reply before the last request-phase data skb is released.  The rxrpc skb
      destructor is where the ACK processing is done and the call state is
      advanced upon release of the last skb.  ACK generation is also deferred to
      a work item because it's possible that the skb destructor is not called in
      a context where kernel_sendmsg() can be invoked.
      
      To this end, the following changes are made:
      
       (1) kernel_rxrpc_data_consumed() is added.  This should be called whenever
           an skb is emptied so as to crank the ACK and call states.  This does
           not release the skb, however.  kernel_rxrpc_free_skb() must now be
           called to achieve that.  These together replace
           rxrpc_kernel_data_delivered().
      
       (2) kernel_rxrpc_data_consumed() is wrapped by afs_data_consumed().
      
           This makes afs_deliver_to_call() easier to work as the skb can simply
           be discarded unconditionally here without trying to work out what the
           return value of the ->deliver() function means.
      
           The ->deliver() functions can, via afs_data_complete(),
           afs_transfer_reply() and afs_extract_data() mark that an skb has been
           consumed (thereby cranking the state) without the need to
           conditionally free the skb to make sure the state is correct on an
           incoming call for when the call processor tries to send the reply.
      
       (3) rxrpc_recvmsg() now has to call kernel_rxrpc_data_consumed() when it
           has finished with a packet and MSG_PEEK isn't set.
      
       (4) rxrpc_packet_destructor() no longer calls rxrpc_hard_ACK_data().
      
           Because of this, we no longer need to clear the destructor and put the
           call before we free the skb in cases where we don't want the ACK/call
           state to be cranked.
      
       (5) The ->deliver() call-type callbacks are made to return -EAGAIN rather
           than 0 if they expect more data (afs_extract_data() returns -EAGAIN to
           the delivery function already), and the caller is now responsible for
           producing an abort if that was the last packet.
      
       (6) There are many bits of unmarshalling code where:
      
       		ret = afs_extract_data(call, skb, last, ...);
      		switch (ret) {
      		case 0:		break;
      		case -EAGAIN:	return 0;
      		default:	return ret;
      		}
      
           is to be found.  As -EAGAIN can now be passed back to the caller, we
           now just return if ret < 0:
      
       		ret = afs_extract_data(call, skb, last, ...);
      		if (ret < 0)
      			return ret;
      
       (7) Checks for trailing data and empty final data packets has been
           consolidated as afs_data_complete().  So:
      
      		if (skb->len > 0)
      			return -EBADMSG;
      		if (!last)
      			return 0;
      
           becomes:
      
      		ret = afs_data_complete(call, skb, last);
      		if (ret < 0)
      			return ret;
      
       (8) afs_transfer_reply() now checks the amount of data it has against the
           amount of data desired and the amount of data in the skb and returns
           an error to induce an abort if we don't get exactly what we want.
      
      Without these changes, the following oops can occasionally be observed,
      particularly if some printks are inserted into the delivery path:
      
      general protection fault: 0000 [#1] SMP
      Modules linked in: kafs(E) af_rxrpc(E) [last unloaded: af_rxrpc]
      CPU: 0 PID: 1305 Comm: kworker/u8:3 Tainted: G            E   4.7.0-fsdevel+ #1303
      Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014
      Workqueue: kafsd afs_async_workfn [kafs]
      task: ffff88040be041c0 ti: ffff88040c070000 task.ti: ffff88040c070000
      RIP: 0010:[<ffffffff8108fd3c>]  [<ffffffff8108fd3c>] __lock_acquire+0xcf/0x15a1
      RSP: 0018:ffff88040c073bc0  EFLAGS: 00010002
      RAX: 6b6b6b6b6b6b6b6b RBX: 0000000000000000 RCX: ffff88040d29a710
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88040d29a710
      RBP: ffff88040c073c70 R08: 0000000000000001 R09: 0000000000000001
      R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
      R13: 0000000000000000 R14: ffff88040be041c0 R15: ffffffff814c928f
      FS:  0000000000000000(0000) GS:ffff88041fa00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007fa4595f4750 CR3: 0000000001c14000 CR4: 00000000001406f0
      Stack:
       0000000000000006 000000000be04930 0000000000000000 ffff880400000000
       ffff880400000000 ffffffff8108f847 ffff88040be041c0 ffffffff81050446
       ffff8803fc08a920 ffff8803fc08a958 ffff88040be041c0 ffff88040c073c38
      Call Trace:
       [<ffffffff8108f847>] ? mark_held_locks+0x5e/0x74
       [<ffffffff81050446>] ? __local_bh_enable_ip+0x9b/0xa1
       [<ffffffff8108f9ca>] ? trace_hardirqs_on_caller+0x16d/0x189
       [<ffffffff810915f4>] lock_acquire+0x122/0x1b6
       [<ffffffff810915f4>] ? lock_acquire+0x122/0x1b6
       [<ffffffff814c928f>] ? skb_dequeue+0x18/0x61
       [<ffffffff81609dbf>] _raw_spin_lock_irqsave+0x35/0x49
       [<ffffffff814c928f>] ? skb_dequeue+0x18/0x61
       [<ffffffff814c928f>] skb_dequeue+0x18/0x61
       [<ffffffffa009aa92>] afs_deliver_to_call+0x344/0x39d [kafs]
       [<ffffffffa009ab37>] afs_process_async_call+0x4c/0xd5 [kafs]
       [<ffffffffa0099e9c>] afs_async_workfn+0xe/0x10 [kafs]
       [<ffffffff81063a3a>] process_one_work+0x29d/0x57c
       [<ffffffff81064ac2>] worker_thread+0x24a/0x385
       [<ffffffff81064878>] ? rescuer_thread+0x2d0/0x2d0
       [<ffffffff810696f5>] kthread+0xf3/0xfb
       [<ffffffff8160a6ff>] ret_from_fork+0x1f/0x40
       [<ffffffff81069602>] ? kthread_create_on_node+0x1cf/0x1cf
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      372ee163
    • Kees Cook's avatar
      ramoops: use DT reserved-memory bindings · 529182e2
      Kees Cook authored
      Instead of a ramoops-specific node, use a child node of /reserved-memory.
      This requires that of_platform_device_create() be explicitly called
      for the node, though, since "/reserved-memory" does not have its own
      "compatible" property.
      Suggested-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Acked-by: default avatarRob Herring <robh@kernel.org>
      529182e2
  21. 04 Aug, 2016 3 commits
  22. 03 Aug, 2016 1 commit
    • Prarit Bhargava's avatar
      modules: Add kernel parameter to blacklist modules · be7de5f9
      Prarit Bhargava authored
      Blacklisting a module in linux has long been a problem.  The current
      procedure is to use rd.blacklist=module_name, however, that doesn't
      cover the case after the initramfs and before a boot prompt (where one
      is supposed to use /etc/modprobe.d/blacklist.conf to blacklist
      runtime loading). Using rd.shell to get an early prompt is hit-or-miss,
      and doesn't cover all situations AFAICT.
      
      This patch adds this functionality of permanently blacklisting a module
      by its name via the kernel parameter module_blacklist=module_name.
      
      [v2]: Rusty, use core_param() instead of __setup() which simplifies
      things.
      
      [v3]: Rusty, undo wreckage from strsep()
      
      [v4]: Rusty, simpler version of blacklisted()
      Signed-off-by: default avatarPrarit Bhargava <prarit@redhat.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: linux-doc@vger.kernel.org
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      be7de5f9