Skip to content

Add support for 2 MCP2515 CAN bus Chips #1049

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

Closed
wants to merge 4 commits into from
Closed

Add support for 2 MCP2515 CAN bus Chips #1049

wants to merge 4 commits into from

Conversation

petit-miner
Copy link

I hope I made everything right.
The file was tested and it worked perfectly.

/* needed to avoid dtc warning */
#address-cells = <1>;
#size-cells = <0>;
can1: mcp2515@0 {
Copy link
Contributor

Choose a reason for hiding this comment

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

This would be better as:

can1: mcp2515@1 {

@pelwell
Copy link
Contributor

pelwell commented Jul 7, 2015

The rest of it looks fine. If you can fix the things I commented on, squash the commits down to one, and git push -f to update the PR, then I'll merge it.

@petit-miner
Copy link
Author

How do I delete the commits and what I have to do next?
It is my first time I work with github and I dont know what I should do.

@pelwell
Copy link
Contributor

pelwell commented Jul 8, 2015

If you have a set of commits like this then you can squash them on your Pi/PC using the "git rebase -i" command. Count how many commits you want to squash then write:

git rebase -i HEAD~n

where n is the number of commits. This will open your chosen editor with a sequence of commits, applied top to bottom, with a keyword (pick) saying what to do with it. If you change all but the first (i.e. from the second commit onwards) to squash then it will create a new commit covering them all, writing you a combined commit message. If the later commits don't add anything worth commenting on, then change the keywords to fixup instead.

When you have a single good commit then you can update the pull request using:

git push -f

@petit-miner petit-miner deleted the rpi-4.1.y branch July 10, 2015 10:53
pelwell pushed a commit that referenced this pull request Jul 10, 2015
pelwell pushed a commit that referenced this pull request Jul 10, 2015
popcornmix pushed a commit that referenced this pull request Jul 13, 2015
pelwell pushed a commit that referenced this pull request Jul 21, 2015
popcornmix pushed a commit that referenced this pull request Jul 24, 2015
popcornmix pushed a commit that referenced this pull request Jul 27, 2015
popcornmix pushed a commit that referenced this pull request Aug 4, 2015
popcornmix pushed a commit that referenced this pull request Aug 5, 2015
popcornmix pushed a commit that referenced this pull request Aug 17, 2015
popcornmix pushed a commit that referenced this pull request Aug 20, 2015
popcornmix pushed a commit that referenced this pull request Sep 2, 2015
popcornmix pushed a commit that referenced this pull request Sep 14, 2015
popcornmix pushed a commit that referenced this pull request Sep 14, 2015
popcornmix pushed a commit that referenced this pull request Sep 22, 2015
popcornmix pushed a commit that referenced this pull request Sep 22, 2015
popcornmix pushed a commit that referenced this pull request Oct 1, 2015
popcornmix pushed a commit that referenced this pull request Oct 3, 2015
popcornmix pushed a commit that referenced this pull request Oct 3, 2015
popcornmix pushed a commit that referenced this pull request Oct 6, 2015
popcornmix pushed a commit that referenced this pull request Oct 7, 2015
popcornmix pushed a commit that referenced this pull request Oct 8, 2015
popcornmix pushed a commit that referenced this pull request Oct 8, 2015
popcornmix pushed a commit that referenced this pull request Oct 9, 2015
popcornmix pushed a commit that referenced this pull request Oct 23, 2015
popcornmix pushed a commit that referenced this pull request Oct 25, 2015
popcornmix pushed a commit that referenced this pull request Oct 27, 2015
popcornmix pushed a commit that referenced this pull request Oct 28, 2015
popcornmix pushed a commit that referenced this pull request Nov 13, 2015
popcornmix pushed a commit that referenced this pull request Dec 10, 2015
popcornmix pushed a commit that referenced this pull request Dec 15, 2015
popcornmix pushed a commit that referenced this pull request Feb 20, 2016
popcornmix pushed a commit that referenced this pull request Apr 18, 2017
The following warning triggers with a new unit test that stresses the
device-dax interface.

 ===============================
 [ ERR: suspicious RCU usage.  ]
 4.11.0-rc4+ #1049 Tainted: G           O
 -------------------------------
 ./include/linux/rcupdate.h:521 Illegal context switch in RCU read-side critical section!

 other info that might help us debug this:

 rcu_scheduler_active = 2, debug_locks = 0
 2 locks held by fio/9070:
  #0:  (&mm->mmap_sem){++++++}, at: [<ffffffff8d0739d7>] __do_page_fault+0x167/0x4f0
  #1:  (rcu_read_lock){......}, at: [<ffffffffc03fbd02>] dax_dev_huge_fault+0x32/0x620 [dax]

 Call Trace:
  dump_stack+0x86/0xc3
  lockdep_rcu_suspicious+0xd7/0x110
  ___might_sleep+0xac/0x250
  __might_sleep+0x4a/0x80
  __alloc_pages_nodemask+0x23a/0x360
  alloc_pages_current+0xa1/0x1f0
  pte_alloc_one+0x17/0x80
  __pte_alloc+0x1e/0x120
  __get_locked_pte+0x1bf/0x1d0
  insert_pfn.isra.70+0x3a/0x100
  ? lookup_memtype+0xa6/0xd0
  vm_insert_mixed+0x64/0x90
  dax_dev_huge_fault+0x520/0x620 [dax]
  ? dax_dev_huge_fault+0x32/0x620 [dax]
  dax_dev_fault+0x10/0x20 [dax]
  __do_fault+0x1e/0x140
  __handle_mm_fault+0x9af/0x10d0
  handle_mm_fault+0x16d/0x370
  ? handle_mm_fault+0x47/0x370
  __do_page_fault+0x28c/0x4f0
  trace_do_page_fault+0x58/0x2a0
  do_async_page_fault+0x1a/0xa0
  async_page_fault+0x28/0x30

Inserting a page table entry may trigger an allocation while we are
holding a read lock to keep the device instance alive for the duration
of the fault. Use srcu for this keep-alive protection.

Fixes: dee4107 ("/dev/dax, core: file operations and dax-mmap")
Cc: <[email protected]>
Signed-off-by: Dan Williams <[email protected]>
popcornmix pushed a commit that referenced this pull request Apr 27, 2017
commit 956a4cd upstream.

The following warning triggers with a new unit test that stresses the
device-dax interface.

 ===============================
 [ ERR: suspicious RCU usage.  ]
 4.11.0-rc4+ #1049 Tainted: G           O
 -------------------------------
 ./include/linux/rcupdate.h:521 Illegal context switch in RCU read-side critical section!

 other info that might help us debug this:

 rcu_scheduler_active = 2, debug_locks = 0
 2 locks held by fio/9070:
  #0:  (&mm->mmap_sem){++++++}, at: [<ffffffff8d0739d7>] __do_page_fault+0x167/0x4f0
  #1:  (rcu_read_lock){......}, at: [<ffffffffc03fbd02>] dax_dev_huge_fault+0x32/0x620 [dax]

 Call Trace:
  dump_stack+0x86/0xc3
  lockdep_rcu_suspicious+0xd7/0x110
  ___might_sleep+0xac/0x250
  __might_sleep+0x4a/0x80
  __alloc_pages_nodemask+0x23a/0x360
  alloc_pages_current+0xa1/0x1f0
  pte_alloc_one+0x17/0x80
  __pte_alloc+0x1e/0x120
  __get_locked_pte+0x1bf/0x1d0
  insert_pfn.isra.70+0x3a/0x100
  ? lookup_memtype+0xa6/0xd0
  vm_insert_mixed+0x64/0x90
  dax_dev_huge_fault+0x520/0x620 [dax]
  ? dax_dev_huge_fault+0x32/0x620 [dax]
  dax_dev_fault+0x10/0x20 [dax]
  __do_fault+0x1e/0x140
  __handle_mm_fault+0x9af/0x10d0
  handle_mm_fault+0x16d/0x370
  ? handle_mm_fault+0x47/0x370
  __do_page_fault+0x28c/0x4f0
  trace_do_page_fault+0x58/0x2a0
  do_async_page_fault+0x1a/0xa0
  async_page_fault+0x28/0x30

Inserting a page table entry may trigger an allocation while we are
holding a read lock to keep the device instance alive for the duration
of the fault. Use srcu for this keep-alive protection.

Fixes: dee4107 ("/dev/dax, core: file operations and dax-mmap")
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
ED6E0F17 pushed a commit to ED6E0F17/linux that referenced this pull request Apr 28, 2017
commit 956a4cd upstream.

The following warning triggers with a new unit test that stresses the
device-dax interface.

 ===============================
 [ ERR: suspicious RCU usage.  ]
 4.11.0-rc4+ raspberrypi#1049 Tainted: G           O
 -------------------------------
 ./include/linux/rcupdate.h:521 Illegal context switch in RCU read-side critical section!

 other info that might help us debug this:

 rcu_scheduler_active = 2, debug_locks = 0
 2 locks held by fio/9070:
  #0:  (&mm->mmap_sem){++++++}, at: [<ffffffff8d0739d7>] __do_page_fault+0x167/0x4f0
  raspberrypi#1:  (rcu_read_lock){......}, at: [<ffffffffc03fbd02>] dax_dev_huge_fault+0x32/0x620 [dax]

 Call Trace:
  dump_stack+0x86/0xc3
  lockdep_rcu_suspicious+0xd7/0x110
  ___might_sleep+0xac/0x250
  __might_sleep+0x4a/0x80
  __alloc_pages_nodemask+0x23a/0x360
  alloc_pages_current+0xa1/0x1f0
  pte_alloc_one+0x17/0x80
  __pte_alloc+0x1e/0x120
  __get_locked_pte+0x1bf/0x1d0
  insert_pfn.isra.70+0x3a/0x100
  ? lookup_memtype+0xa6/0xd0
  vm_insert_mixed+0x64/0x90
  dax_dev_huge_fault+0x520/0x620 [dax]
  ? dax_dev_huge_fault+0x32/0x620 [dax]
  dax_dev_fault+0x10/0x20 [dax]
  __do_fault+0x1e/0x140
  __handle_mm_fault+0x9af/0x10d0
  handle_mm_fault+0x16d/0x370
  ? handle_mm_fault+0x47/0x370
  __do_page_fault+0x28c/0x4f0
  trace_do_page_fault+0x58/0x2a0
  do_async_page_fault+0x1a/0xa0
  async_page_fault+0x28/0x30

Inserting a page table entry may trigger an allocation while we are
holding a read lock to keep the device instance alive for the duration
of the fault. Use srcu for this keep-alive protection.

Fixes: dee4107 ("/dev/dax, core: file operations and dax-mmap")
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
popcornmix pushed a commit that referenced this pull request Apr 28, 2017
commit 956a4cd upstream.

The following warning triggers with a new unit test that stresses the
device-dax interface.

 ===============================
 [ ERR: suspicious RCU usage.  ]
 4.11.0-rc4+ #1049 Tainted: G           O
 -------------------------------
 ./include/linux/rcupdate.h:521 Illegal context switch in RCU read-side critical section!

 other info that might help us debug this:

 rcu_scheduler_active = 2, debug_locks = 0
 2 locks held by fio/9070:
  #0:  (&mm->mmap_sem){++++++}, at: [<ffffffff8d0739d7>] __do_page_fault+0x167/0x4f0
  #1:  (rcu_read_lock){......}, at: [<ffffffffc03fbd02>] dax_dev_huge_fault+0x32/0x620 [dax]

 Call Trace:
  dump_stack+0x86/0xc3
  lockdep_rcu_suspicious+0xd7/0x110
  ___might_sleep+0xac/0x250
  __might_sleep+0x4a/0x80
  __alloc_pages_nodemask+0x23a/0x360
  alloc_pages_current+0xa1/0x1f0
  pte_alloc_one+0x17/0x80
  __pte_alloc+0x1e/0x120
  __get_locked_pte+0x1bf/0x1d0
  insert_pfn.isra.70+0x3a/0x100
  ? lookup_memtype+0xa6/0xd0
  vm_insert_mixed+0x64/0x90
  dax_dev_huge_fault+0x520/0x620 [dax]
  ? dax_dev_huge_fault+0x32/0x620 [dax]
  dax_dev_fault+0x10/0x20 [dax]
  __do_fault+0x1e/0x140
  __handle_mm_fault+0x9af/0x10d0
  handle_mm_fault+0x16d/0x370
  ? handle_mm_fault+0x47/0x370
  __do_page_fault+0x28c/0x4f0
  trace_do_page_fault+0x58/0x2a0
  do_async_page_fault+0x1a/0xa0
  async_page_fault+0x28/0x30

Inserting a page table entry may trigger an allocation while we are
holding a read lock to keep the device instance alive for the duration
of the fault. Use srcu for this keep-alive protection.

Fixes: dee4107 ("/dev/dax, core: file operations and dax-mmap")
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
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.

2 participants