Re: [PATCH 05/11] DT: marvell,mmp2: Add SSP1 and SSP3
On Wed, Oct 10, 2018 at 07:09:30PM +0200, Lubomir Rintel wrote: > There seem to be SSP2, SSP4 and perhaps SSP5 too, but Marvel keeps their > base addresses secret. > > The SSP1 and SSP3 addresses were taken from OLPC 1.75, OpenFirmware and > kernel respectively. Sorry for the delay. Love your work! From my notes, SSP2 is 0xd4036000, and SSP4 is 0xd4039000. Can be probed by hand in OpenFirmware or CForth once clocks are on. -- James Cameron http://quozl.netrek.org/
Re: [PATCH 05/11] DT: marvell,mmp2: Add SSP1 and SSP3
On Wed, Oct 10, 2018 at 07:09:30PM +0200, Lubomir Rintel wrote: > There seem to be SSP2, SSP4 and perhaps SSP5 too, but Marvel keeps their > base addresses secret. > > The SSP1 and SSP3 addresses were taken from OLPC 1.75, OpenFirmware and > kernel respectively. Sorry for the delay. Love your work! From my notes, SSP2 is 0xd4036000, and SSP4 is 0xd4039000. Can be probed by hand in OpenFirmware or CForth once clocks are on. -- James Cameron http://quozl.netrek.org/
Loan Offer
Contact Allstate Funding Corporation ® for small and large loans amount. We give out loan all kinds of loan at 2% interest rate. We also give out from. $5000 thousand Dollars to 20 million Dollars for individuals and companies, the credit is open to all regardless of nationality. NOTE: All response must e forwarded to: gylesloan...@gmail.com Allstate Funding Corporation ® E-mail: gylesloan...@gmail.com Company Phone Number: (+144)22040140 --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: [PATCH V2 1/3] blk-mq: refactor the code of issue request directly
Hi Ming On 10/29/18 10:49 AM, Ming Lei wrote: > On Sat, Oct 27, 2018 at 12:01:09AM +0800, Jianchao Wang wrote: >> Merge blk_mq_try_issue_directly and __blk_mq_try_issue_directly >> into one interface which is able to handle the return value from >> .queue_rq callback. Due to we can only issue directly w/o io >> scheduler, so remove the blk_mq_get_driver_tag. > > It isn't correct for dm-rq, see blk_insert_cloned_request(). > Yes, got it. when the original requests are issued to the underlying paths as cloned requests, they should not pass through the io scheduler. Thanks Jianchao
Loan Offer
Contact Allstate Funding Corporation ® for small and large loans amount. We give out loan all kinds of loan at 2% interest rate. We also give out from. $5000 thousand Dollars to 20 million Dollars for individuals and companies, the credit is open to all regardless of nationality. NOTE: All response must e forwarded to: gylesloan...@gmail.com Allstate Funding Corporation ® E-mail: gylesloan...@gmail.com Company Phone Number: (+144)22040140 --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: [PATCH V2 1/3] blk-mq: refactor the code of issue request directly
Hi Ming On 10/29/18 10:49 AM, Ming Lei wrote: > On Sat, Oct 27, 2018 at 12:01:09AM +0800, Jianchao Wang wrote: >> Merge blk_mq_try_issue_directly and __blk_mq_try_issue_directly >> into one interface which is able to handle the return value from >> .queue_rq callback. Due to we can only issue directly w/o io >> scheduler, so remove the blk_mq_get_driver_tag. > > It isn't correct for dm-rq, see blk_insert_cloned_request(). > Yes, got it. when the original requests are issued to the underlying paths as cloned requests, they should not pass through the io scheduler. Thanks Jianchao
Re: [GIT PULL] Devicetree updates for 4.20
Hi Rob, On Fri, Oct 26, 2018 at 9:07 AM Rob Herring wrote: > > Linus, > > Please pull DT updates for 4.20. A bit bigger than normal as I've been > busy this cycle. There's a few things with dependencies and a few > things subsystem maintainers didn't pick up, so I'm taking them thru > my tree. The fixes from Johan didn't get into linux-next, but they've > been waiting for some time now and they are what's left of what > subsystem maintainers didn't pick up. There's no conflicts yet with > your tree, but there are 2 conflicts I'm aware of. One is with the c6x > tree and the other is in drivers/soc/qcom/apr.c. The correct > resolutions are in linux-next. > [...] > scripts/dtc: Update to upstream version v1.4.7-14-gc86da84d30e4 This update made dtc spit out a large number of warnings on a regular build, due to a new requirement that a SPI node is named "spi". Seems like an arbitrary restriction, but either way can the warning please be disabled by default until them cleaned up so we don't have a bunch of noise in the logs? An example ARM allmodconfig: http://arm-soc.lixom.net/buildlogs/mainline/v4.19-9418-g9f51ae62c84a2/buildall.arm.allmodconfig.log.passed (162 warnings). Thanks, -Olof
Re: [GIT PULL] Devicetree updates for 4.20
Hi Rob, On Fri, Oct 26, 2018 at 9:07 AM Rob Herring wrote: > > Linus, > > Please pull DT updates for 4.20. A bit bigger than normal as I've been > busy this cycle. There's a few things with dependencies and a few > things subsystem maintainers didn't pick up, so I'm taking them thru > my tree. The fixes from Johan didn't get into linux-next, but they've > been waiting for some time now and they are what's left of what > subsystem maintainers didn't pick up. There's no conflicts yet with > your tree, but there are 2 conflicts I'm aware of. One is with the c6x > tree and the other is in drivers/soc/qcom/apr.c. The correct > resolutions are in linux-next. > [...] > scripts/dtc: Update to upstream version v1.4.7-14-gc86da84d30e4 This update made dtc spit out a large number of warnings on a regular build, due to a new requirement that a SPI node is named "spi". Seems like an arbitrary restriction, but either way can the warning please be disabled by default until them cleaned up so we don't have a bunch of noise in the logs? An example ARM allmodconfig: http://arm-soc.lixom.net/buildlogs/mainline/v4.19-9418-g9f51ae62c84a2/buildall.arm.allmodconfig.log.passed (162 warnings). Thanks, -Olof
Re: [PATCH] xhci: Add quirk to workaround the errata seen on Cavium Thunder-X2 Soc
Hi Alan, Thanks for the review. I will update the patch accordingly and send out v2. On 10/28/2018 10:48 PM, Alan Stern wrote: > > On Sat, 27 Oct 2018, Cherian, George wrote: > >> Implement workaround for ThunderX2 Errata-129 (documented in >> CN99XX Known Issues" available at Cavium support site). >> As per ThunderX2errata-129, USB-2.0 device may come up as USB-1.0 >> If a connection to a USB-1.0 device is followed by another connection >> to a USB-2.0 device, the link will come up as USB-1.0 for the USB-2.0 >> device. >> >> Resolution: Reset the PHY after the USB1.0 device is disconnected. >> The PHY reset sequence is done using private registers in XHCI register >> space. After the PHY is reset we check for the PLL lock status and retry >> the operation if it fails. From our tests, retrying 4 times is sufficient. >> >> Add a new quirk flag XHCI_RESET_PLL_ON_DISCONNECT to invoke the workaround >> in handle_xhci_port_status(). > > Minor nitpick (for both the patch description and the code comments): > > USB 1.0 was never widely adopted and is not used any more. The > earliest vesion of USB currently used in supported devices is USB 1.1. > Likewise, there are a few devices around that support USB 2.1, not > USB 2.0, but they are presumably also subject to the problem described > above. > > I suggest you change the description and the comments to refer to USB 1 > and USB 2 instead of USB 1.0 and USB 2.0, as the latter are too > restrictive and misleading. > > Alan Stern > Regards, -George
Re: [PATCH] xhci: Add quirk to workaround the errata seen on Cavium Thunder-X2 Soc
Hi Alan, Thanks for the review. I will update the patch accordingly and send out v2. On 10/28/2018 10:48 PM, Alan Stern wrote: > > On Sat, 27 Oct 2018, Cherian, George wrote: > >> Implement workaround for ThunderX2 Errata-129 (documented in >> CN99XX Known Issues" available at Cavium support site). >> As per ThunderX2errata-129, USB-2.0 device may come up as USB-1.0 >> If a connection to a USB-1.0 device is followed by another connection >> to a USB-2.0 device, the link will come up as USB-1.0 for the USB-2.0 >> device. >> >> Resolution: Reset the PHY after the USB1.0 device is disconnected. >> The PHY reset sequence is done using private registers in XHCI register >> space. After the PHY is reset we check for the PLL lock status and retry >> the operation if it fails. From our tests, retrying 4 times is sufficient. >> >> Add a new quirk flag XHCI_RESET_PLL_ON_DISCONNECT to invoke the workaround >> in handle_xhci_port_status(). > > Minor nitpick (for both the patch description and the code comments): > > USB 1.0 was never widely adopted and is not used any more. The > earliest vesion of USB currently used in supported devices is USB 1.1. > Likewise, there are a few devices around that support USB 2.1, not > USB 2.0, but they are presumably also subject to the problem described > above. > > I suggest you change the description and the comments to refer to USB 1 > and USB 2 instead of USB 1.0 and USB 2.0, as the latter are too > restrictive and misleading. > > Alan Stern > Regards, -George
Re: [PATCH 1/2] mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings
On Tue, Sep 25, 2018 at 02:03:25PM +0200, Michal Hocko wrote: > From: Andrea Arcangeli > > THP allocation might be really disruptive when allocated on NUMA system > with the local node full or hard to reclaim. Stefan has posted an > allocation stall report on 4.12 based SLES kernel which suggests the > same issue: > > [245513.362669] kvm: page allocation stalls for 194572ms, order:9, > mode:0x4740ca(__GFP_HIGHMEM|__GFP_IO|__GFP_FS|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_HARDWALL|__GFP_THISNODE|__GFP_MOVABLE|__GFP_DIRECT_RECLAIM), > nodemask=(null) > [245513.363983] kvm cpuset=/ mems_allowed=0-1 > [245513.364604] CPU: 10 PID: 84752 Comm: kvm Tainted: GW 4.12.0+98-ph > class="resolved">001 SLE15 (unreleased) > [245513.365258] Hardware name: Supermicro SYS-1029P-WTRT/X11DDW-NT, BIOS 2.0 > 12/05/2017 > [245513.365905] Call Trace: > [245513.366535] dump_stack+0x5c/0x84 > [245513.367148] warn_alloc+0xe0/0x180 > [245513.367769] __alloc_pages_slowpath+0x820/0xc90 > [245513.368406] ? __slab_free+0xa9/0x2f0 > [245513.369048] ? __slab_free+0xa9/0x2f0 > [245513.369671] __alloc_pages_nodemask+0x1cc/0x210 > [245513.370300] alloc_pages_vma+0x1e5/0x280 > [245513.370921] do_huge_pmd_wp_page+0x83f/0xf00 > [245513.371554] ? set_huge_zero_page.isra.52.part.53+0x9b/0xb0 > [245513.372184] ? do_huge_pmd_anonymous_page+0x631/0x6d0 > [245513.372812] __handle_mm_fault+0x93d/0x1060 > [245513.373439] handle_mm_fault+0xc6/0x1b0 > [245513.374042] __do_page_fault+0x230/0x430 > [245513.374679] ? get_vtime_delta+0x13/0xb0 > [245513.375411] do_page_fault+0x2a/0x70 > [245513.376145] ? page_fault+0x65/0x80 > [245513.376882] page_fault+0x7b/0x80 > [...] > [245513.382056] Mem-Info: > [245513.382634] active_anon:126315487 inactive_anon:1612476 isolated_anon:5 > active_file:60183 inactive_file:245285 isolated_file:0 > unevictable:15657 dirty:286 writeback:1 unstable:0 > slab_reclaimable:75543 slab_unreclaimable:2509111 > mapped:81814 shmem:31764 pagetables:370616 bounce:0 > free:32294031 free_pcp:6233 free_cma:0 > [245513.386615] Node 0 active_anon:254680388kB inactive_anon:1112760kB > active_file:240648kB inactive_file:981168kB unevictable:13368kB > isolated(anon):0kB isolated(file):0kB mapped:280240kB dirty:1144kB > writeback:0kB shmem:95832kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: > 81225728kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no > [245513.388650] Node 1 active_anon:250583072kB inactive_anon:5337144kB > active_file:84kB inactive_file:0kB unevictable:49260kB isolated(anon):20kB > isolated(file):0kB mapped:47016kB dirty:0kB writeback:4kB shmem:31224kB > shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 31897600kB writeback_tmp:0kB > unstable:0kB all_unreclaimable? no > > The defrag mode is "madvise" and from the above report it is clear that > the THP has been allocated for MADV_HUGEPAGA vma. > > Andrea has identified that the main source of the problem is > __GFP_THISNODE usage: > > : The problem is that direct compaction combined with the NUMA > : __GFP_THISNODE logic in mempolicy.c is telling reclaim to swap very > : hard the local node, instead of failing the allocation if there's no > : THP available in the local node. > : > : Such logic was ok until __GFP_THISNODE was added to the THP allocation > : path even with MPOL_DEFAULT. > : > : The idea behind the __GFP_THISNODE addition, is that it is better to > : provide local memory in PAGE_SIZE units than to use remote NUMA THP > : backed memory. That largely depends on the remote latency though, on > : threadrippers for example the overhead is relatively low in my > : experience. > : > : The combination of __GFP_THISNODE and __GFP_DIRECT_RECLAIM results in > : extremely slow qemu startup with vfio, if the VM is larger than the > : size of one host NUMA node. This is because it will try very hard to > : unsuccessfully swapout get_user_pages pinned pages as result of the > : __GFP_THISNODE being set, instead of falling back to PAGE_SIZE > : allocations and instead of trying to allocate THP on other nodes (it > : would be even worse without vfio type1 GUP pins of course, except it'd > : be swapping heavily instead). > > Fix this by removing __GFP_THISNODE for THP requests which are > requesting the direct reclaim. This effectivelly reverts 5265047ac301 on > the grounds that the zone/node reclaim was known to be disruptive due > to premature reclaim when there was memory free. While it made sense at > the time for HPC workloads without NUMA awareness on rare machines, it > was ultimately harmful in the majority of cases. The existing behaviour > is similiar, if not as widespare as it applies to a corner case but > crucially, it cannot be tuned around like zone_reclaim_mode can. The > default behaviour should always be to cause the least harm for the > common case. > > If there are specialised use cases out there that want zone_reclaim_mode > in
Re: [PATCH 1/2] mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings
On Tue, Sep 25, 2018 at 02:03:25PM +0200, Michal Hocko wrote: > From: Andrea Arcangeli > > THP allocation might be really disruptive when allocated on NUMA system > with the local node full or hard to reclaim. Stefan has posted an > allocation stall report on 4.12 based SLES kernel which suggests the > same issue: > > [245513.362669] kvm: page allocation stalls for 194572ms, order:9, > mode:0x4740ca(__GFP_HIGHMEM|__GFP_IO|__GFP_FS|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_HARDWALL|__GFP_THISNODE|__GFP_MOVABLE|__GFP_DIRECT_RECLAIM), > nodemask=(null) > [245513.363983] kvm cpuset=/ mems_allowed=0-1 > [245513.364604] CPU: 10 PID: 84752 Comm: kvm Tainted: GW 4.12.0+98-ph > class="resolved">001 SLE15 (unreleased) > [245513.365258] Hardware name: Supermicro SYS-1029P-WTRT/X11DDW-NT, BIOS 2.0 > 12/05/2017 > [245513.365905] Call Trace: > [245513.366535] dump_stack+0x5c/0x84 > [245513.367148] warn_alloc+0xe0/0x180 > [245513.367769] __alloc_pages_slowpath+0x820/0xc90 > [245513.368406] ? __slab_free+0xa9/0x2f0 > [245513.369048] ? __slab_free+0xa9/0x2f0 > [245513.369671] __alloc_pages_nodemask+0x1cc/0x210 > [245513.370300] alloc_pages_vma+0x1e5/0x280 > [245513.370921] do_huge_pmd_wp_page+0x83f/0xf00 > [245513.371554] ? set_huge_zero_page.isra.52.part.53+0x9b/0xb0 > [245513.372184] ? do_huge_pmd_anonymous_page+0x631/0x6d0 > [245513.372812] __handle_mm_fault+0x93d/0x1060 > [245513.373439] handle_mm_fault+0xc6/0x1b0 > [245513.374042] __do_page_fault+0x230/0x430 > [245513.374679] ? get_vtime_delta+0x13/0xb0 > [245513.375411] do_page_fault+0x2a/0x70 > [245513.376145] ? page_fault+0x65/0x80 > [245513.376882] page_fault+0x7b/0x80 > [...] > [245513.382056] Mem-Info: > [245513.382634] active_anon:126315487 inactive_anon:1612476 isolated_anon:5 > active_file:60183 inactive_file:245285 isolated_file:0 > unevictable:15657 dirty:286 writeback:1 unstable:0 > slab_reclaimable:75543 slab_unreclaimable:2509111 > mapped:81814 shmem:31764 pagetables:370616 bounce:0 > free:32294031 free_pcp:6233 free_cma:0 > [245513.386615] Node 0 active_anon:254680388kB inactive_anon:1112760kB > active_file:240648kB inactive_file:981168kB unevictable:13368kB > isolated(anon):0kB isolated(file):0kB mapped:280240kB dirty:1144kB > writeback:0kB shmem:95832kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: > 81225728kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no > [245513.388650] Node 1 active_anon:250583072kB inactive_anon:5337144kB > active_file:84kB inactive_file:0kB unevictable:49260kB isolated(anon):20kB > isolated(file):0kB mapped:47016kB dirty:0kB writeback:4kB shmem:31224kB > shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 31897600kB writeback_tmp:0kB > unstable:0kB all_unreclaimable? no > > The defrag mode is "madvise" and from the above report it is clear that > the THP has been allocated for MADV_HUGEPAGA vma. > > Andrea has identified that the main source of the problem is > __GFP_THISNODE usage: > > : The problem is that direct compaction combined with the NUMA > : __GFP_THISNODE logic in mempolicy.c is telling reclaim to swap very > : hard the local node, instead of failing the allocation if there's no > : THP available in the local node. > : > : Such logic was ok until __GFP_THISNODE was added to the THP allocation > : path even with MPOL_DEFAULT. > : > : The idea behind the __GFP_THISNODE addition, is that it is better to > : provide local memory in PAGE_SIZE units than to use remote NUMA THP > : backed memory. That largely depends on the remote latency though, on > : threadrippers for example the overhead is relatively low in my > : experience. > : > : The combination of __GFP_THISNODE and __GFP_DIRECT_RECLAIM results in > : extremely slow qemu startup with vfio, if the VM is larger than the > : size of one host NUMA node. This is because it will try very hard to > : unsuccessfully swapout get_user_pages pinned pages as result of the > : __GFP_THISNODE being set, instead of falling back to PAGE_SIZE > : allocations and instead of trying to allocate THP on other nodes (it > : would be even worse without vfio type1 GUP pins of course, except it'd > : be swapping heavily instead). > > Fix this by removing __GFP_THISNODE for THP requests which are > requesting the direct reclaim. This effectivelly reverts 5265047ac301 on > the grounds that the zone/node reclaim was known to be disruptive due > to premature reclaim when there was memory free. While it made sense at > the time for HPC workloads without NUMA awareness on rare machines, it > was ultimately harmful in the majority of cases. The existing behaviour > is similiar, if not as widespare as it applies to a corner case but > crucially, it cannot be tuned around like zone_reclaim_mode can. The > default behaviour should always be to cause the least harm for the > common case. > > If there are specialised use cases out there that want zone_reclaim_mode > in
[PATCH v3] mm/page_owner: use kvmalloc instead of kmalloc
From: Miles Chen The kbuf used by page owner is allocated by kmalloc(), which means it can use only normal memory and there might be a "out of memory" issue when we're out of normal memory. To solve this problem, use kvmalloc() to allocate kbuf from normal/highmem. But there is one problem here: kvmalloc() does not fallback to vmalloc for sub page allocations. So sub page allocation fails due to out of normal memory cannot fallback to vmalloc. Modify kvmalloc() to allow sub page allocations fallback to vmalloc when CONFIG_HIGHMEM=y and use kvmalloc() to allocate kbuf. Clamp buffer size to PAGE_SIZE to avoid arbitrary size allocation. Change since v2: - improve kvmalloc, allow sub page allocations fallback to vmalloc when CONFIG_HIGHMEM=y Change since v1: - use kvmalloc() - clamp buffer size to PAGE_SIZE Signed-off-by: Miles Chen Cc: Joe Perches Cc: Matthew Wilcox Cc: Michal Hocko --- mm/page_owner.c | 8 mm/util.c | 6 +++--- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/mm/page_owner.c b/mm/page_owner.c index d80adfe702d3..a064cd046361 100644 --- a/mm/page_owner.c +++ b/mm/page_owner.c @@ -1,7 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 #include #include -#include #include #include #include @@ -351,7 +350,8 @@ print_page_owner(char __user *buf, size_t count, unsigned long pfn, .skip = 0 }; - kbuf = kmalloc(count, GFP_KERNEL); + count = count > PAGE_SIZE ? PAGE_SIZE : count; + kbuf = kvmalloc(count, GFP_KERNEL); if (!kbuf) return -ENOMEM; @@ -397,11 +397,11 @@ print_page_owner(char __user *buf, size_t count, unsigned long pfn, if (copy_to_user(buf, kbuf, ret)) ret = -EFAULT; - kfree(kbuf); + kvfree(kbuf); return ret; err: - kfree(kbuf); + kvfree(kbuf); return -ENOMEM; } diff --git a/mm/util.c b/mm/util.c index 8bf08b5b5760..7b1c59b9bfbf 100644 --- a/mm/util.c +++ b/mm/util.c @@ -416,10 +416,10 @@ void *kvmalloc_node(size_t size, gfp_t flags, int node) ret = kmalloc_node(size, kmalloc_flags, node); /* -* It doesn't really make sense to fallback to vmalloc for sub page -* requests +* It only makes sense to fallback to vmalloc for sub page +* requests if we might be able to allocate highmem pages. */ - if (ret || size <= PAGE_SIZE) + if (ret || (!IS_ENABLED(CONFIG_HIGHMEM) && size <= PAGE_SIZE)) return ret; return __vmalloc_node_flags_caller(size, node, flags, -- 2.18.0
[PATCH v3] mm/page_owner: use kvmalloc instead of kmalloc
From: Miles Chen The kbuf used by page owner is allocated by kmalloc(), which means it can use only normal memory and there might be a "out of memory" issue when we're out of normal memory. To solve this problem, use kvmalloc() to allocate kbuf from normal/highmem. But there is one problem here: kvmalloc() does not fallback to vmalloc for sub page allocations. So sub page allocation fails due to out of normal memory cannot fallback to vmalloc. Modify kvmalloc() to allow sub page allocations fallback to vmalloc when CONFIG_HIGHMEM=y and use kvmalloc() to allocate kbuf. Clamp buffer size to PAGE_SIZE to avoid arbitrary size allocation. Change since v2: - improve kvmalloc, allow sub page allocations fallback to vmalloc when CONFIG_HIGHMEM=y Change since v1: - use kvmalloc() - clamp buffer size to PAGE_SIZE Signed-off-by: Miles Chen Cc: Joe Perches Cc: Matthew Wilcox Cc: Michal Hocko --- mm/page_owner.c | 8 mm/util.c | 6 +++--- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/mm/page_owner.c b/mm/page_owner.c index d80adfe702d3..a064cd046361 100644 --- a/mm/page_owner.c +++ b/mm/page_owner.c @@ -1,7 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 #include #include -#include #include #include #include @@ -351,7 +350,8 @@ print_page_owner(char __user *buf, size_t count, unsigned long pfn, .skip = 0 }; - kbuf = kmalloc(count, GFP_KERNEL); + count = count > PAGE_SIZE ? PAGE_SIZE : count; + kbuf = kvmalloc(count, GFP_KERNEL); if (!kbuf) return -ENOMEM; @@ -397,11 +397,11 @@ print_page_owner(char __user *buf, size_t count, unsigned long pfn, if (copy_to_user(buf, kbuf, ret)) ret = -EFAULT; - kfree(kbuf); + kvfree(kbuf); return ret; err: - kfree(kbuf); + kvfree(kbuf); return -ENOMEM; } diff --git a/mm/util.c b/mm/util.c index 8bf08b5b5760..7b1c59b9bfbf 100644 --- a/mm/util.c +++ b/mm/util.c @@ -416,10 +416,10 @@ void *kvmalloc_node(size_t size, gfp_t flags, int node) ret = kmalloc_node(size, kmalloc_flags, node); /* -* It doesn't really make sense to fallback to vmalloc for sub page -* requests +* It only makes sense to fallback to vmalloc for sub page +* requests if we might be able to allocate highmem pages. */ - if (ret || size <= PAGE_SIZE) + if (ret || (!IS_ENABLED(CONFIG_HIGHMEM) && size <= PAGE_SIZE)) return ret; return __vmalloc_node_flags_caller(size, node, flags, -- 2.18.0
Re: [RFR] Store tearing
On Sun, Oct 28, 2018 at 06:20:42PM -0700, Paul E. McKenney wrote: > On Mon, Oct 29, 2018 at 12:10:03AM +0100, Andrea Parri wrote: > > Hopefully, with Paul's proper email address this time, > > > > Andrea > > > > On Mon, Oct 29, 2018 at 12:06:27AM +0100, Andrea Parri wrote: > > > Hi, > > > > > > memory-barriers.txt says: > > > > > > [on "store tearing"] > > > > > > "In fact, a recent bug (since fixed) caused GCC to incorrectly use > > >this optimization in a volatile store.". > > > > > > I was wondering if you could help me retrieve some reference/discussions > > > about this? > > This was quite some time ago, but it involved a 32-bit volatile store > of a constant such as 0x10001. The machine in question had a narrow > store-immediate instruction, so the compiler emitted a pair of 16-bit > store-immediate instructions. This bug was fixed, though only after > significant screaming and shouting. That does sound like an interesting discussion. ;D Thanks for the info, Andrea > > Thanx, Paul >
Re: [RFR] Store tearing
On Sun, Oct 28, 2018 at 06:20:42PM -0700, Paul E. McKenney wrote: > On Mon, Oct 29, 2018 at 12:10:03AM +0100, Andrea Parri wrote: > > Hopefully, with Paul's proper email address this time, > > > > Andrea > > > > On Mon, Oct 29, 2018 at 12:06:27AM +0100, Andrea Parri wrote: > > > Hi, > > > > > > memory-barriers.txt says: > > > > > > [on "store tearing"] > > > > > > "In fact, a recent bug (since fixed) caused GCC to incorrectly use > > >this optimization in a volatile store.". > > > > > > I was wondering if you could help me retrieve some reference/discussions > > > about this? > > This was quite some time ago, but it involved a 32-bit volatile store > of a constant such as 0x10001. The machine in question had a narrow > store-immediate instruction, so the compiler emitted a pair of 16-bit > store-immediate instructions. This bug was fixed, though only after > significant screaming and shouting. That does sound like an interesting discussion. ;D Thanks for the info, Andrea > > Thanx, Paul >
[REQUEST FOR CODE INTEGRATION - L4.25-L5.05] Parallelization and binary trees with huge dimensions
When I have time I’ll have to read a few books and dig into the latest kernel to really understand what the Linux kernel is, but during that procrastination I want to rewrite the Linux scheduler using my code, it’s basically a binary tree with a bunch of fixed variables with a rotating DMA that cleans up excess pointers. It can be used as an integrated SQL database (because of char*’s and binary trees) and depending on what multidimension you init the arrays, it will take huge amounts of ram You can easily go up one indice by adding a number to the indice that makes the array go up, im sorry its med time for me But my intentions is to make my code its own operating system. The Quantum moniker is a marketing buzzword, its really made for binary trees with HUGE dimensions (im talking about bt[200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200]; (sorry if thats spammy) If this isnt relevant to the Linux kernel, please disregard My code is at GitHub, at unidef/quantum for convenience: git clone https://github.com/unidef/quantum qwork/ I appreciate any feedback, and I would love to be actively involved in Linux kernel development Also just like in EQ2, Linux could use a really memory hungry mode, I have 32gb of ram on all my computers and multitasking (especially in Linux) is really, really fun! Abja
[REQUEST FOR CODE INTEGRATION - L4.25-L5.05] Parallelization and binary trees with huge dimensions
When I have time I’ll have to read a few books and dig into the latest kernel to really understand what the Linux kernel is, but during that procrastination I want to rewrite the Linux scheduler using my code, it’s basically a binary tree with a bunch of fixed variables with a rotating DMA that cleans up excess pointers. It can be used as an integrated SQL database (because of char*’s and binary trees) and depending on what multidimension you init the arrays, it will take huge amounts of ram You can easily go up one indice by adding a number to the indice that makes the array go up, im sorry its med time for me But my intentions is to make my code its own operating system. The Quantum moniker is a marketing buzzword, its really made for binary trees with HUGE dimensions (im talking about bt[200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200][200]; (sorry if thats spammy) If this isnt relevant to the Linux kernel, please disregard My code is at GitHub, at unidef/quantum for convenience: git clone https://github.com/unidef/quantum qwork/ I appreciate any feedback, and I would love to be actively involved in Linux kernel development Also just like in EQ2, Linux could use a really memory hungry mode, I have 32gb of ram on all my computers and multitasking (especially in Linux) is really, really fun! Abja
Re: linux-next: build failure after merge of the vfs tree
Hi Al, David,
These have returned, so I have disabled CONFIG_SAMPLE_VFS again.
On Mon, 10 Sep 2018 13:35:25 +1000 Stephen Rothwell
wrote:
>
> After merging the vfs tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> samples/vfs/test-fsinfo.c: In function 'fsinfo':
> samples/vfs/test-fsinfo.c:37:17: error: '__NR_fsinfo' undeclared (first use
> in this function); did you mean 'fsinfo'?
> return syscall(__NR_fsinfo, dfd, filename, params, buffer, buf_size);
> ^~~
> fsinfo
> samples/vfs/test-fsinfo.c:37:17: note: each undeclared identifier is reported
> only once for each function it appears in
> samples/vfs/test-fsinfo.c: In function 'dump_attr_LIMITS':
> samples/vfs/test-fsinfo.c:180:30: warning: format '%llx' expects argument of
> type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long
> unsigned int'} [-Wformat=]
> printf("\tmax file size: %llx\n", f->max_file_size);
>~~~^
>%lx
> samples/vfs/test-fsinfo.c:181:32: warning: format '%llx' expects argument of
> type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long
> unsigned int'} [-Wformat=]
> printf("\tmax ids : u=%llx g=%llx p=%llx\n",
> ~~~^
> %lx
> f->max_uid, f->max_gid, f->max_projid);
> ~~
> samples/vfs/test-fsinfo.c:181:39: warning: format '%llx' expects argument of
> type 'long long unsigned int', but argument 3 has type '__u64' {aka 'long
> unsigned int'} [-Wformat=]
> printf("\tmax ids : u=%llx g=%llx p=%llx\n",
> ~~~^
> %lx
> f->max_uid, f->max_gid, f->max_projid);
> ~~
> samples/vfs/test-fsinfo.c:181:46: warning: format '%llx' expects argument of
> type 'long long unsigned int', but argument 4 has type '__u64' {aka 'long
> unsigned int'} [-Wformat=]
> printf("\tmax ids : u=%llx g=%llx p=%llx\n",
>~~~^
>%lx
> f->max_uid, f->max_gid, f->max_projid);
> ~
> samples/vfs/test-fsinfo.c: In function 'dump_attr_SUPPORTS':
> samples/vfs/test-fsinfo.c:197:24: warning: format '%llx' expects argument of
> type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long
> unsigned int'} [-Wformat=]
> printf("\tstx_attr=%llx\n", f->stx_attributes);
> ~~~^ ~
> %lx
> samples/vfs/test-fsmount.c: In function 'fsopen':
> samples/vfs/test-fsmount.c:63:17: error: '__NR_fsopen' undeclared (first use
> in this function); did you mean 'fsopen'?
> return syscall(__NR_fsopen, fs_name, flags);
> ^~~
> fsopen
> samples/vfs/test-fsmount.c:63:17: note: each undeclared identifier is
> reported only once for each function it appears in
> samples/vfs/test-fsmount.c: In function 'fsmount':
> samples/vfs/test-fsmount.c:68:17: error: '__NR_fsmount' undeclared (first use
> in this function); did you mean 'fsmount'?
> return syscall(__NR_fsmount, fsfd, flags, ms_flags);
> ^~~~
> fsmount
> samples/vfs/test-fsmount.c: In function 'fsconfig':
> samples/vfs/test-fsmount.c:74:17: error: '__NR_fsconfig' undeclared (first
> use in this function); did you mean 'fsconfig'?
> return syscall(__NR_fsconfig, fsfd, cmd, key, val, aux);
> ^
> fsconfig
> samples/vfs/test-fsmount.c: In function 'move_mount':
> samples/vfs/test-fsmount.c:81:17: error: '__NR_move_mount' undeclared (first
> use in this function); did you mean 'move_mount'?
> return syscall(__NR_move_mount,
> ^~~
> move_mount
> samples/vfs/test-fs-query.c: In function 'fsopen':
> samples/vfs/test-fs-query.c:32:17: error: '__NR_fsopen' undeclared (first use
> in this function); did you mean 'fsopen'?
> return syscall(__NR_fsopen, fs_name, flags);
> ^~~
> fsopen
> samples/vfs/test-fs-query.c:32:17: note: each undeclared identifier is
> reported only once for each function it appears in
> samples/vfs/test-fs-query.c: In function 'fsinfo':
> samples/vfs/test-fs-query.c:38:17: error: '__NR_fsinfo' undeclared (first use
> in this function); did you mean 'fsinfo'?
> return syscall(__NR_fsinfo, dfd, filename, params, buffer, buf_size);
> ^~~
> fsinfo
> samples/vfs/test-statx.c: In function 'dump_statx':
> samples/vfs/test-statx.c:160:29: warning: format '%llx' expects argument of
> type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long
> unsigned int'} [-Wformat=]
>printf("Attributes: %016llx (", stx->stx_attributes);
>
Re: linux-next: build failure after merge of the vfs tree
Hi Al, David,
These have returned, so I have disabled CONFIG_SAMPLE_VFS again.
On Mon, 10 Sep 2018 13:35:25 +1000 Stephen Rothwell
wrote:
>
> After merging the vfs tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> samples/vfs/test-fsinfo.c: In function 'fsinfo':
> samples/vfs/test-fsinfo.c:37:17: error: '__NR_fsinfo' undeclared (first use
> in this function); did you mean 'fsinfo'?
> return syscall(__NR_fsinfo, dfd, filename, params, buffer, buf_size);
> ^~~
> fsinfo
> samples/vfs/test-fsinfo.c:37:17: note: each undeclared identifier is reported
> only once for each function it appears in
> samples/vfs/test-fsinfo.c: In function 'dump_attr_LIMITS':
> samples/vfs/test-fsinfo.c:180:30: warning: format '%llx' expects argument of
> type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long
> unsigned int'} [-Wformat=]
> printf("\tmax file size: %llx\n", f->max_file_size);
>~~~^
>%lx
> samples/vfs/test-fsinfo.c:181:32: warning: format '%llx' expects argument of
> type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long
> unsigned int'} [-Wformat=]
> printf("\tmax ids : u=%llx g=%llx p=%llx\n",
> ~~~^
> %lx
> f->max_uid, f->max_gid, f->max_projid);
> ~~
> samples/vfs/test-fsinfo.c:181:39: warning: format '%llx' expects argument of
> type 'long long unsigned int', but argument 3 has type '__u64' {aka 'long
> unsigned int'} [-Wformat=]
> printf("\tmax ids : u=%llx g=%llx p=%llx\n",
> ~~~^
> %lx
> f->max_uid, f->max_gid, f->max_projid);
> ~~
> samples/vfs/test-fsinfo.c:181:46: warning: format '%llx' expects argument of
> type 'long long unsigned int', but argument 4 has type '__u64' {aka 'long
> unsigned int'} [-Wformat=]
> printf("\tmax ids : u=%llx g=%llx p=%llx\n",
>~~~^
>%lx
> f->max_uid, f->max_gid, f->max_projid);
> ~
> samples/vfs/test-fsinfo.c: In function 'dump_attr_SUPPORTS':
> samples/vfs/test-fsinfo.c:197:24: warning: format '%llx' expects argument of
> type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long
> unsigned int'} [-Wformat=]
> printf("\tstx_attr=%llx\n", f->stx_attributes);
> ~~~^ ~
> %lx
> samples/vfs/test-fsmount.c: In function 'fsopen':
> samples/vfs/test-fsmount.c:63:17: error: '__NR_fsopen' undeclared (first use
> in this function); did you mean 'fsopen'?
> return syscall(__NR_fsopen, fs_name, flags);
> ^~~
> fsopen
> samples/vfs/test-fsmount.c:63:17: note: each undeclared identifier is
> reported only once for each function it appears in
> samples/vfs/test-fsmount.c: In function 'fsmount':
> samples/vfs/test-fsmount.c:68:17: error: '__NR_fsmount' undeclared (first use
> in this function); did you mean 'fsmount'?
> return syscall(__NR_fsmount, fsfd, flags, ms_flags);
> ^~~~
> fsmount
> samples/vfs/test-fsmount.c: In function 'fsconfig':
> samples/vfs/test-fsmount.c:74:17: error: '__NR_fsconfig' undeclared (first
> use in this function); did you mean 'fsconfig'?
> return syscall(__NR_fsconfig, fsfd, cmd, key, val, aux);
> ^
> fsconfig
> samples/vfs/test-fsmount.c: In function 'move_mount':
> samples/vfs/test-fsmount.c:81:17: error: '__NR_move_mount' undeclared (first
> use in this function); did you mean 'move_mount'?
> return syscall(__NR_move_mount,
> ^~~
> move_mount
> samples/vfs/test-fs-query.c: In function 'fsopen':
> samples/vfs/test-fs-query.c:32:17: error: '__NR_fsopen' undeclared (first use
> in this function); did you mean 'fsopen'?
> return syscall(__NR_fsopen, fs_name, flags);
> ^~~
> fsopen
> samples/vfs/test-fs-query.c:32:17: note: each undeclared identifier is
> reported only once for each function it appears in
> samples/vfs/test-fs-query.c: In function 'fsinfo':
> samples/vfs/test-fs-query.c:38:17: error: '__NR_fsinfo' undeclared (first use
> in this function); did you mean 'fsinfo'?
> return syscall(__NR_fsinfo, dfd, filename, params, buffer, buf_size);
> ^~~
> fsinfo
> samples/vfs/test-statx.c: In function 'dump_statx':
> samples/vfs/test-statx.c:160:29: warning: format '%llx' expects argument of
> type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long
> unsigned int'} [-Wformat=]
>printf("Attributes: %016llx (", stx->stx_attributes);
>
Re: Cramfs: "unable to handle kernel paging request" when reading a file from a fuzzed FS image
On Sun, 28 Oct 2018, Anatoly Trosinenko wrote: > Hello, > > When reading a file from a fuzzed cramfs image, unhandled kernel > paging request occurs. Hmmm... It doesn't show up on my test system. > How to reproduce with kvm-xfstests: > 1) Checkout the v4.19 tag, copy x86_64-config-4.14 to .config, perform > `make olddefconfig` > 2) Enable Cramfs in the config, then compile > 3) In the `kvm-xfstests shell` perform: > > root@kvm-xfstests:~# mount /vtmp > root@kvm-xfstests:~# mount /vtmp/cramfs.img /mnt How do I populate /vtmp? Mine is empty at this point. I imagine I should put the cramfs image somewhere on the host, but I'm not that familiar withkvm. Nicolas
Re: Cramfs: "unable to handle kernel paging request" when reading a file from a fuzzed FS image
On Sun, 28 Oct 2018, Anatoly Trosinenko wrote: > Hello, > > When reading a file from a fuzzed cramfs image, unhandled kernel > paging request occurs. Hmmm... It doesn't show up on my test system. > How to reproduce with kvm-xfstests: > 1) Checkout the v4.19 tag, copy x86_64-config-4.14 to .config, perform > `make olddefconfig` > 2) Enable Cramfs in the config, then compile > 3) In the `kvm-xfstests shell` perform: > > root@kvm-xfstests:~# mount /vtmp > root@kvm-xfstests:~# mount /vtmp/cramfs.img /mnt How do I populate /vtmp? Mine is empty at this point. I imagine I should put the cramfs image somewhere on the host, but I'm not that familiar withkvm. Nicolas
Re: [PATCH v4 0/4] m68k: system call table generation support
Hi Geert,
On Sat, 27 Oct 2018 at 20:17, Geert Uytterhoeven wrote:
>
> Hi Firoz,
>
> On Fri, Oct 26, 2018 at 7:06 AM Firoz Khan wrote:
> > The purpose of this patch series is, we can easily add/modify/delete
> > system call table support by changing entry in syscall.tbl file
> > instead of manually changing many files. The other goal is to unify
> > the system call table generation support implementation across all
> > the architectures.
> >
> > The system call tables are in different format in all architecture.
> > It will be difficult to manually add, modify or delete the system
> > calls in the respective files manually. To make it easy by keeping
> > a script and which'll generate uapi header file and syscall table
> > file.
> >
> > syscall.tbl contains the list of available system calls along with
> > system call number and corresponding entry point. Add a new system
> > call in this architecture will be possible by adding new entry in
> > the syscall.tbl file.
> >
> > Adding a new table entry consisting of:
> > - System call number.
> > - ABI.
> > - System call name.
> > - Entry point name.
> >
> > ARM, s390 and x86 architecuture does exist the similar support. I
> > leverage their implementation to come up with a generic solution.
> >
> > I have done the same support for work for alpha, ia64, microblaze,
> > mips, parisc, powerpc, sh, sparc, and xtensa. Below mentioned git
> > repository contains more details.
> > Git repo:- https://github.com/frzkhn/system_call_table_generator/
> >
> > Finally, this is the ground work to solve the Y2038 issue. We need
> > to add two dozen of system calls to solve Y2038 issue. So this patch
> > series will help to add new system calls easily by adding new entry
> > in the syscall.tbl.
>
> Thanks for the update!
>
> Can you please tell the audience what has been changed in v4?
Sure.
- I added the comments in syscall.tbl and solved mixed (space and tab)
indentation.
- Modified the scripts (syscalltbl.sh and syscallhdr.sh) as per the feedback
provided by Arnd, Finn Thain, Eugene Syromiatnikov and Rolf Eike Beer.
Eg:-
- echo options are not portable; changed to printf
- "let" is a bash extension; changed posix-conformant expression.
- Finally I optimized the script and solved mixed indentation.
>
> When posting a new version of a patch or patch series, it is a good
> idea to include a changelog in the cover letter and/or patches.
Sure, will do!
Thanks
Firoz
>
> Thanks!
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
Re: [PATCH v4 0/4] m68k: system call table generation support
Hi Geert,
On Sat, 27 Oct 2018 at 20:17, Geert Uytterhoeven wrote:
>
> Hi Firoz,
>
> On Fri, Oct 26, 2018 at 7:06 AM Firoz Khan wrote:
> > The purpose of this patch series is, we can easily add/modify/delete
> > system call table support by changing entry in syscall.tbl file
> > instead of manually changing many files. The other goal is to unify
> > the system call table generation support implementation across all
> > the architectures.
> >
> > The system call tables are in different format in all architecture.
> > It will be difficult to manually add, modify or delete the system
> > calls in the respective files manually. To make it easy by keeping
> > a script and which'll generate uapi header file and syscall table
> > file.
> >
> > syscall.tbl contains the list of available system calls along with
> > system call number and corresponding entry point. Add a new system
> > call in this architecture will be possible by adding new entry in
> > the syscall.tbl file.
> >
> > Adding a new table entry consisting of:
> > - System call number.
> > - ABI.
> > - System call name.
> > - Entry point name.
> >
> > ARM, s390 and x86 architecuture does exist the similar support. I
> > leverage their implementation to come up with a generic solution.
> >
> > I have done the same support for work for alpha, ia64, microblaze,
> > mips, parisc, powerpc, sh, sparc, and xtensa. Below mentioned git
> > repository contains more details.
> > Git repo:- https://github.com/frzkhn/system_call_table_generator/
> >
> > Finally, this is the ground work to solve the Y2038 issue. We need
> > to add two dozen of system calls to solve Y2038 issue. So this patch
> > series will help to add new system calls easily by adding new entry
> > in the syscall.tbl.
>
> Thanks for the update!
>
> Can you please tell the audience what has been changed in v4?
Sure.
- I added the comments in syscall.tbl and solved mixed (space and tab)
indentation.
- Modified the scripts (syscalltbl.sh and syscallhdr.sh) as per the feedback
provided by Arnd, Finn Thain, Eugene Syromiatnikov and Rolf Eike Beer.
Eg:-
- echo options are not portable; changed to printf
- "let" is a bash extension; changed posix-conformant expression.
- Finally I optimized the script and solved mixed indentation.
>
> When posting a new version of a patch or patch series, it is a good
> idea to include a changelog in the cover letter and/or patches.
Sure, will do!
Thanks
Firoz
>
> Thanks!
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
Re: [v2, PATCH 0/2] add Ethernet driver support for mt2712
On Mon, 2018-10-29 at 11:04 +0800, Biao Huang wrote: > The mt2712 Ethernet IP is from Synopsys, so extend stmmac to support mt2712. > sorry, I forgot to add detail descriptions for these patches. changes in v2: --since STMMAC driver applied to most Synopsys ip Ethernet, I add dwmac-mediatek.c to support MediaTek mt2712 in v2. --abandon Ethernet drivers proposed in v1. --rewrite dt-binding document for v2 driver. Best Regards!
Re: [v2, PATCH 0/2] add Ethernet driver support for mt2712
On Mon, 2018-10-29 at 11:04 +0800, Biao Huang wrote: > The mt2712 Ethernet IP is from Synopsys, so extend stmmac to support mt2712. > sorry, I forgot to add detail descriptions for these patches. changes in v2: --since STMMAC driver applied to most Synopsys ip Ethernet, I add dwmac-mediatek.c to support MediaTek mt2712 in v2. --abandon Ethernet drivers proposed in v1. --rewrite dt-binding document for v2 driver. Best Regards!
linux-next: manual merge of the drivers-x86 tree with Linus' tree
Hi all,
Today's linux-next merge of the drivers-x86 tree got a conflict in:
drivers/platform/x86/intel_telemetry_debugfs.c
between commit:
f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming")
from Linus' tree and commit:
1a7938a632ce ("platform/x86: intel_telemetry: Get rid of custom macro")
from the drivers-x86 tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/platform/x86/intel_telemetry_debugfs.c
index cee08f236292,30988e31c713..
--- a/drivers/platform/x86/intel_telemetry_debugfs.c
+++ b/drivers/platform/x86/intel_telemetry_debugfs.c
@@@ -319,8 -308,8 +308,8 @@@ static struct telemetry_debugfs_conf te
};
static const struct x86_cpu_id telemetry_debugfs_cpu_ids[] = {
- TELEM_DEBUGFS_CPU(INTEL_FAM6_ATOM_GOLDMONT, telem_apl_debugfs_conf),
- TELEM_DEBUGFS_CPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS,
telem_apl_debugfs_conf),
+ INTEL_CPU_FAM6(ATOM_GOLDMONT, telem_apl_debugfs_conf),
- INTEL_CPU_FAM6(ATOM_GEMINI_LAKE, telem_apl_debugfs_conf),
++ INTEL_CPU_FAM6(ATOM_GOLDMONT_PLUS, telem_apl_debugfs_conf),
{}
};
pgpwPx4zj0j1z.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the drivers-x86 tree with Linus' tree
Hi all,
Today's linux-next merge of the drivers-x86 tree got a conflict in:
drivers/platform/x86/intel_telemetry_debugfs.c
between commit:
f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming")
from Linus' tree and commit:
1a7938a632ce ("platform/x86: intel_telemetry: Get rid of custom macro")
from the drivers-x86 tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/platform/x86/intel_telemetry_debugfs.c
index cee08f236292,30988e31c713..
--- a/drivers/platform/x86/intel_telemetry_debugfs.c
+++ b/drivers/platform/x86/intel_telemetry_debugfs.c
@@@ -319,8 -308,8 +308,8 @@@ static struct telemetry_debugfs_conf te
};
static const struct x86_cpu_id telemetry_debugfs_cpu_ids[] = {
- TELEM_DEBUGFS_CPU(INTEL_FAM6_ATOM_GOLDMONT, telem_apl_debugfs_conf),
- TELEM_DEBUGFS_CPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS,
telem_apl_debugfs_conf),
+ INTEL_CPU_FAM6(ATOM_GOLDMONT, telem_apl_debugfs_conf),
- INTEL_CPU_FAM6(ATOM_GEMINI_LAKE, telem_apl_debugfs_conf),
++ INTEL_CPU_FAM6(ATOM_GOLDMONT_PLUS, telem_apl_debugfs_conf),
{}
};
pgpwPx4zj0j1z.pgp
Description: OpenPGP digital signature
[PATCH V3 2/5] misc/pvpanic : convert to SPDX license tags
This patch updates license to use SPDX-License-Identifier instead of verbose license text. Signed-off-by: Peng Hao --- drivers/misc/pvpanic.c | 17 ++--- 1 file changed, 2 insertions(+), 15 deletions(-) diff --git a/drivers/misc/pvpanic.c b/drivers/misc/pvpanic.c index fd86dab..9450376 100644 --- a/drivers/misc/pvpanic.c +++ b/drivers/misc/pvpanic.c @@ -1,21 +1,8 @@ +// SPDX-License-Identifier: GPL-2.0+ /* - * pvpanic.c - pvpanic Device Support + * Pvpanic Device Support * * Copyright (C) 2013 Fujitsu. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA */ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt -- 1.8.3.1
[PATCH V3 2/5] misc/pvpanic : convert to SPDX license tags
This patch updates license to use SPDX-License-Identifier instead of verbose license text. Signed-off-by: Peng Hao --- drivers/misc/pvpanic.c | 17 ++--- 1 file changed, 2 insertions(+), 15 deletions(-) diff --git a/drivers/misc/pvpanic.c b/drivers/misc/pvpanic.c index fd86dab..9450376 100644 --- a/drivers/misc/pvpanic.c +++ b/drivers/misc/pvpanic.c @@ -1,21 +1,8 @@ +// SPDX-License-Identifier: GPL-2.0+ /* - * pvpanic.c - pvpanic Device Support + * Pvpanic Device Support * * Copyright (C) 2013 Fujitsu. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA */ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt -- 1.8.3.1
[PATCH V3 1/5] pvpanic: move pvpanic to misc as common driver
move pvpanic.c from drivers/platform/x86 to drivers/misc.
following patches will use pvpanic device in arm64.
Signed-off-by: Peng Hao
---
drivers/misc/Kconfig | 7 +++
drivers/misc/Makefile | 1 +
drivers/misc/pvpanic.c | 124 +
drivers/platform/Kconfig | 3 +
drivers/platform/Makefile | 1 +
drivers/platform/x86/Kconfig | 8 ---
drivers/platform/x86/Makefile | 1 -
drivers/platform/x86/pvpanic.c | 124 -
8 files changed, 136 insertions(+), 133 deletions(-)
create mode 100644 drivers/misc/pvpanic.c
delete mode 100644 drivers/platform/x86/pvpanic.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 5d71300..ca55c94 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -499,6 +499,13 @@ config MISC_RTSX
tristate
default MISC_RTSX_PCI || MISC_RTSX_USB
+config PVPANIC
+ tristate "pvpanic device support"
+ help
+ This driver provides support for the pvpanic device. pvpanic is
+ a paravirtualized device provided by QEMU; it lets a virtual machine
+ (guest) communicate panic events to the host.
+
source "drivers/misc/c2port/Kconfig"
source "drivers/misc/eeprom/Kconfig"
source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 20be70c..39dc005 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -57,3 +57,4 @@ obj-$(CONFIG_ASPEED_LPC_SNOOP)+= aspeed-lpc-snoop.o
obj-$(CONFIG_PCI_ENDPOINT_TEST)+= pci_endpoint_test.o
obj-$(CONFIG_OCXL) += ocxl/
obj-$(CONFIG_MISC_RTSX)+= cardreader/
+obj-$(CONFIG_PVPANIC) += pvpanic.o
diff --git a/drivers/misc/pvpanic.c b/drivers/misc/pvpanic.c
new file mode 100644
index 000..fd86dab
--- /dev/null
+++ b/drivers/misc/pvpanic.c
@@ -0,0 +1,124 @@
+/*
+ * pvpanic.c - pvpanic Device Support
+ *
+ * Copyright (C) 2013 Fujitsu.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
USA
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include
+#include
+#include
+#include
+#include
+
+MODULE_AUTHOR("Hu Tao ");
+MODULE_DESCRIPTION("pvpanic device driver");
+MODULE_LICENSE("GPL");
+
+static int pvpanic_add(struct acpi_device *device);
+static int pvpanic_remove(struct acpi_device *device);
+
+static const struct acpi_device_id pvpanic_device_ids[] = {
+ { "QEMU0001", 0 },
+ { "", 0 },
+};
+MODULE_DEVICE_TABLE(acpi, pvpanic_device_ids);
+
+#define PVPANIC_PANICKED (1 << 0)
+
+static u16 port;
+
+static struct acpi_driver pvpanic_driver = {
+ .name = "pvpanic",
+ .class ="QEMU",
+ .ids = pvpanic_device_ids,
+ .ops = {
+ .add = pvpanic_add,
+ .remove = pvpanic_remove,
+ },
+ .owner =THIS_MODULE,
+};
+
+static void
+pvpanic_send_event(unsigned int event)
+{
+ outb(event, port);
+}
+
+static int
+pvpanic_panic_notify(struct notifier_block *nb, unsigned long code,
+void *unused)
+{
+ pvpanic_send_event(PVPANIC_PANICKED);
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block pvpanic_panic_nb = {
+ .notifier_call = pvpanic_panic_notify,
+ .priority = 1, /* let this called before broken drm_fb_helper */
+};
+
+
+static acpi_status
+pvpanic_walk_resources(struct acpi_resource *res, void *context)
+{
+ switch (res->type) {
+ case ACPI_RESOURCE_TYPE_END_TAG:
+ return AE_OK;
+
+ case ACPI_RESOURCE_TYPE_IO:
+ port = res->data.io.minimum;
+ return AE_OK;
+
+ default:
+ return AE_ERROR;
+ }
+}
+
+static int pvpanic_add(struct acpi_device *device)
+{
+ int ret;
+
+ ret = acpi_bus_get_status(device);
+ if (ret < 0)
+ return ret;
+
+ if (!device->status.enabled || !device->status.functional)
+ return -ENODEV;
+
+ acpi_walk_resources(device->handle, METHOD_NAME__CRS,
+ pvpanic_walk_resources, NULL);
+
+ if (!port)
+ return -ENODEV;
+
+
[PATCH 5/5] dt-bindings/misc/pvpanic :add document for pvpanic-mmio
Add dt-bindings document for "qemu:pvpanic-mmio".
Signed-off-by: Peng Hao
---
.../devicetree/bindings/misc/pvpanic-mmio.txt | 29 ++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/pvpanic-mmio.txt
diff --git a/Documentation/devicetree/bindings/misc/pvpanic-mmio.txt
b/Documentation/devicetree/bindings/misc/pvpanic-mmio.txt
new file mode 100644
index 000..3db6d19
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/pvpanic-mmio.txt
@@ -0,0 +1,29 @@
+* QEMU PVPANIC MMIO Configuration bindings
+
+QEMU's emulation / virtualization targets provide the following PVPANIC
+MMIO Configuration interface on the "virt" machine.
+type:
+
+- a read-write, 16-bit wide data register.
+
+QEMU exposes the data register to guests as memory mapped registers.
+
+Required properties:
+
+- compatible: "qemu,pvpanic-mmio".
+- reg: the MMIO region used by the device.
+ * Bytes 0x0 Write panic event to the reg when guest OS panics.
+ * Bytes 0x1 Reserved.
+
+Example:
+
+/ {
+#size-cells = <0x2>;
+#address-cells = <0x2>;
+
+pvpanic-mmio@906 {
+compatible = "qemu,pvpanic-mmio";
+reg = <0x0 0x906 0x0 0x2>;
+};
+};
+
--
1.8.3.1
[PATCH V3 1/5] pvpanic: move pvpanic to misc as common driver
move pvpanic.c from drivers/platform/x86 to drivers/misc.
following patches will use pvpanic device in arm64.
Signed-off-by: Peng Hao
---
drivers/misc/Kconfig | 7 +++
drivers/misc/Makefile | 1 +
drivers/misc/pvpanic.c | 124 +
drivers/platform/Kconfig | 3 +
drivers/platform/Makefile | 1 +
drivers/platform/x86/Kconfig | 8 ---
drivers/platform/x86/Makefile | 1 -
drivers/platform/x86/pvpanic.c | 124 -
8 files changed, 136 insertions(+), 133 deletions(-)
create mode 100644 drivers/misc/pvpanic.c
delete mode 100644 drivers/platform/x86/pvpanic.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 5d71300..ca55c94 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -499,6 +499,13 @@ config MISC_RTSX
tristate
default MISC_RTSX_PCI || MISC_RTSX_USB
+config PVPANIC
+ tristate "pvpanic device support"
+ help
+ This driver provides support for the pvpanic device. pvpanic is
+ a paravirtualized device provided by QEMU; it lets a virtual machine
+ (guest) communicate panic events to the host.
+
source "drivers/misc/c2port/Kconfig"
source "drivers/misc/eeprom/Kconfig"
source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 20be70c..39dc005 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -57,3 +57,4 @@ obj-$(CONFIG_ASPEED_LPC_SNOOP)+= aspeed-lpc-snoop.o
obj-$(CONFIG_PCI_ENDPOINT_TEST)+= pci_endpoint_test.o
obj-$(CONFIG_OCXL) += ocxl/
obj-$(CONFIG_MISC_RTSX)+= cardreader/
+obj-$(CONFIG_PVPANIC) += pvpanic.o
diff --git a/drivers/misc/pvpanic.c b/drivers/misc/pvpanic.c
new file mode 100644
index 000..fd86dab
--- /dev/null
+++ b/drivers/misc/pvpanic.c
@@ -0,0 +1,124 @@
+/*
+ * pvpanic.c - pvpanic Device Support
+ *
+ * Copyright (C) 2013 Fujitsu.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
USA
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include
+#include
+#include
+#include
+#include
+
+MODULE_AUTHOR("Hu Tao ");
+MODULE_DESCRIPTION("pvpanic device driver");
+MODULE_LICENSE("GPL");
+
+static int pvpanic_add(struct acpi_device *device);
+static int pvpanic_remove(struct acpi_device *device);
+
+static const struct acpi_device_id pvpanic_device_ids[] = {
+ { "QEMU0001", 0 },
+ { "", 0 },
+};
+MODULE_DEVICE_TABLE(acpi, pvpanic_device_ids);
+
+#define PVPANIC_PANICKED (1 << 0)
+
+static u16 port;
+
+static struct acpi_driver pvpanic_driver = {
+ .name = "pvpanic",
+ .class ="QEMU",
+ .ids = pvpanic_device_ids,
+ .ops = {
+ .add = pvpanic_add,
+ .remove = pvpanic_remove,
+ },
+ .owner =THIS_MODULE,
+};
+
+static void
+pvpanic_send_event(unsigned int event)
+{
+ outb(event, port);
+}
+
+static int
+pvpanic_panic_notify(struct notifier_block *nb, unsigned long code,
+void *unused)
+{
+ pvpanic_send_event(PVPANIC_PANICKED);
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block pvpanic_panic_nb = {
+ .notifier_call = pvpanic_panic_notify,
+ .priority = 1, /* let this called before broken drm_fb_helper */
+};
+
+
+static acpi_status
+pvpanic_walk_resources(struct acpi_resource *res, void *context)
+{
+ switch (res->type) {
+ case ACPI_RESOURCE_TYPE_END_TAG:
+ return AE_OK;
+
+ case ACPI_RESOURCE_TYPE_IO:
+ port = res->data.io.minimum;
+ return AE_OK;
+
+ default:
+ return AE_ERROR;
+ }
+}
+
+static int pvpanic_add(struct acpi_device *device)
+{
+ int ret;
+
+ ret = acpi_bus_get_status(device);
+ if (ret < 0)
+ return ret;
+
+ if (!device->status.enabled || !device->status.functional)
+ return -ENODEV;
+
+ acpi_walk_resources(device->handle, METHOD_NAME__CRS,
+ pvpanic_walk_resources, NULL);
+
+ if (!port)
+ return -ENODEV;
+
+
[PATCH 5/5] dt-bindings/misc/pvpanic :add document for pvpanic-mmio
Add dt-bindings document for "qemu:pvpanic-mmio".
Signed-off-by: Peng Hao
---
.../devicetree/bindings/misc/pvpanic-mmio.txt | 29 ++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/pvpanic-mmio.txt
diff --git a/Documentation/devicetree/bindings/misc/pvpanic-mmio.txt
b/Documentation/devicetree/bindings/misc/pvpanic-mmio.txt
new file mode 100644
index 000..3db6d19
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/pvpanic-mmio.txt
@@ -0,0 +1,29 @@
+* QEMU PVPANIC MMIO Configuration bindings
+
+QEMU's emulation / virtualization targets provide the following PVPANIC
+MMIO Configuration interface on the "virt" machine.
+type:
+
+- a read-write, 16-bit wide data register.
+
+QEMU exposes the data register to guests as memory mapped registers.
+
+Required properties:
+
+- compatible: "qemu,pvpanic-mmio".
+- reg: the MMIO region used by the device.
+ * Bytes 0x0 Write panic event to the reg when guest OS panics.
+ * Bytes 0x1 Reserved.
+
+Example:
+
+/ {
+#size-cells = <0x2>;
+#address-cells = <0x2>;
+
+pvpanic-mmio@906 {
+compatible = "qemu,pvpanic-mmio";
+reg = <0x0 0x906 0x0 0x2>;
+};
+};
+
--
1.8.3.1
[PATCH V4 4/5] misc/pvpanic: add support to get pvpanic device info by FDT
By default, when ACPI tables and FDT coexist for ARM64,
current kernel takes precedence over FDT to get device information.
Virt machine in qemu provides both FDT and ACPI table. This patch
increases the way to get information through FDT.
Signed-off-by: Peng Hao
---
drivers/misc/pvpanic.c | 63 +-
1 file changed, 62 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/pvpanic.c b/drivers/misc/pvpanic.c
index cfd7fef..eb1ed0f 100644
--- a/drivers/misc/pvpanic.c
+++ b/drivers/misc/pvpanic.c
@@ -3,15 +3,19 @@
* Pvpanic Device Support
*
* Copyright (C) 2013 Fujitsu.
+ * Copyright (C) 2018 ZTE.
*/
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+#include
+#include
#include
#include
#include
#include
#include
+#include
MODULE_AUTHOR("Hu Tao ");
MODULE_DESCRIPTION("pvpanic device driver");
@@ -60,6 +64,32 @@
.priority = 1, /* let this called before broken drm_fb_helper */
};
+static int pvpanic_mmio_probe(struct platform_device *pdev)
+{
+ struct resource *mem;
+
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!mem)
+ return -EINVAL;
+
+ base = devm_ioremap_resource(>dev, mem);
+ if (base == NULL)
+ return -EFAULT;
+
+ atomic_notifier_chain_register(_notifier_list,
+ _panic_nb);
+
+ return 0;
+}
+
+static int pvpanic_mmio_remove(struct platform_device *pdev)
+{
+
+ atomic_notifier_chain_unregister(_notifier_list,
+_panic_nb);
+
+ return 0;
+}
static acpi_status
pvpanic_walk_resources(struct acpi_resource *res, void *context)
@@ -118,4 +148,35 @@ static int pvpanic_remove(struct acpi_device *device)
return 0;
}
-module_acpi_driver(pvpanic_driver);
+static const struct of_device_id pvpanic_mmio_match[] = {
+ { .compatible = "qemu,pvpanic-mmio", },
+ {}
+};
+
+static struct platform_driver pvpanic_mmio_driver = {
+ .driver = {
+ .name = "pvpanic-mmio",
+ .of_match_table = pvpanic_mmio_match,
+ },
+ .probe = pvpanic_mmio_probe,
+ .remove = pvpanic_mmio_remove,
+};
+
+static int __init pvpanic_mmio_init(void)
+{
+ if (acpi_disabled)
+ return platform_driver_register(_mmio_driver);
+ else
+ return acpi_bus_register_driver(_driver);
+}
+
+static void __exit pvpanic_mmio_exit(void)
+{
+ if (acpi_disabled)
+ platform_driver_unregister(_mmio_driver);
+ else
+ acpi_bus_unregister_driver(_driver);
+}
+
+module_init(pvpanic_mmio_init);
+module_exit(pvpanic_mmio_exit);
--
1.8.3.1
[PATCH V3 3/5] misc/pvpanic: add MMIO support
On some architectures (e.g. arm64), it's preferable to use MMIO, since
this can be used standalone. Add MMIO support to the pvpanic driver.
Signed-off-by: Peng Hao
---
drivers/misc/pvpanic.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/misc/pvpanic.c b/drivers/misc/pvpanic.c
index 9450376..cfd7fef 100644
--- a/drivers/misc/pvpanic.c
+++ b/drivers/misc/pvpanic.c
@@ -28,7 +28,7 @@
#define PVPANIC_PANICKED (1 << 0)
-static u16 port;
+static void __iomem *base;
static struct acpi_driver pvpanic_driver = {
.name = "pvpanic",
@@ -44,7 +44,7 @@
static void
pvpanic_send_event(unsigned int event)
{
- outb(event, port);
+ iowrite8(event, base);
}
static int
@@ -64,12 +64,19 @@
static acpi_status
pvpanic_walk_resources(struct acpi_resource *res, void *context)
{
+ struct acpi_resource_fixed_memory32 *fixmem32;
+
switch (res->type) {
case ACPI_RESOURCE_TYPE_END_TAG:
return AE_OK;
case ACPI_RESOURCE_TYPE_IO:
- port = res->data.io.minimum;
+ base = (void __iomem *) ioport_map(res->data.io.minimum, 1);
+ return AE_OK;
+
+ case ACPI_RESOURCE_TYPE_FIXED_MEMORY32:
+ fixmem32 = >data.fixed_memory32;
+ base = ioremap(fixmem32->address, fixmem32->address_length);
return AE_OK;
default:
@@ -91,7 +98,7 @@ static int pvpanic_add(struct acpi_device *device)
acpi_walk_resources(device->handle, METHOD_NAME__CRS,
pvpanic_walk_resources, NULL);
- if (!port)
+ if (!base)
return -ENODEV;
atomic_notifier_chain_register(_notifier_list,
@@ -105,6 +112,9 @@ static int pvpanic_remove(struct acpi_device *device)
atomic_notifier_chain_unregister(_notifier_list,
_panic_nb);
+
+ iounmap(base);
+
return 0;
}
--
1.8.3.1
[PATCH V4 4/5] misc/pvpanic: add support to get pvpanic device info by FDT
By default, when ACPI tables and FDT coexist for ARM64,
current kernel takes precedence over FDT to get device information.
Virt machine in qemu provides both FDT and ACPI table. This patch
increases the way to get information through FDT.
Signed-off-by: Peng Hao
---
drivers/misc/pvpanic.c | 63 +-
1 file changed, 62 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/pvpanic.c b/drivers/misc/pvpanic.c
index cfd7fef..eb1ed0f 100644
--- a/drivers/misc/pvpanic.c
+++ b/drivers/misc/pvpanic.c
@@ -3,15 +3,19 @@
* Pvpanic Device Support
*
* Copyright (C) 2013 Fujitsu.
+ * Copyright (C) 2018 ZTE.
*/
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+#include
+#include
#include
#include
#include
#include
#include
+#include
MODULE_AUTHOR("Hu Tao ");
MODULE_DESCRIPTION("pvpanic device driver");
@@ -60,6 +64,32 @@
.priority = 1, /* let this called before broken drm_fb_helper */
};
+static int pvpanic_mmio_probe(struct platform_device *pdev)
+{
+ struct resource *mem;
+
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!mem)
+ return -EINVAL;
+
+ base = devm_ioremap_resource(>dev, mem);
+ if (base == NULL)
+ return -EFAULT;
+
+ atomic_notifier_chain_register(_notifier_list,
+ _panic_nb);
+
+ return 0;
+}
+
+static int pvpanic_mmio_remove(struct platform_device *pdev)
+{
+
+ atomic_notifier_chain_unregister(_notifier_list,
+_panic_nb);
+
+ return 0;
+}
static acpi_status
pvpanic_walk_resources(struct acpi_resource *res, void *context)
@@ -118,4 +148,35 @@ static int pvpanic_remove(struct acpi_device *device)
return 0;
}
-module_acpi_driver(pvpanic_driver);
+static const struct of_device_id pvpanic_mmio_match[] = {
+ { .compatible = "qemu,pvpanic-mmio", },
+ {}
+};
+
+static struct platform_driver pvpanic_mmio_driver = {
+ .driver = {
+ .name = "pvpanic-mmio",
+ .of_match_table = pvpanic_mmio_match,
+ },
+ .probe = pvpanic_mmio_probe,
+ .remove = pvpanic_mmio_remove,
+};
+
+static int __init pvpanic_mmio_init(void)
+{
+ if (acpi_disabled)
+ return platform_driver_register(_mmio_driver);
+ else
+ return acpi_bus_register_driver(_driver);
+}
+
+static void __exit pvpanic_mmio_exit(void)
+{
+ if (acpi_disabled)
+ platform_driver_unregister(_mmio_driver);
+ else
+ acpi_bus_unregister_driver(_driver);
+}
+
+module_init(pvpanic_mmio_init);
+module_exit(pvpanic_mmio_exit);
--
1.8.3.1
[PATCH V3 3/5] misc/pvpanic: add MMIO support
On some architectures (e.g. arm64), it's preferable to use MMIO, since
this can be used standalone. Add MMIO support to the pvpanic driver.
Signed-off-by: Peng Hao
---
drivers/misc/pvpanic.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/misc/pvpanic.c b/drivers/misc/pvpanic.c
index 9450376..cfd7fef 100644
--- a/drivers/misc/pvpanic.c
+++ b/drivers/misc/pvpanic.c
@@ -28,7 +28,7 @@
#define PVPANIC_PANICKED (1 << 0)
-static u16 port;
+static void __iomem *base;
static struct acpi_driver pvpanic_driver = {
.name = "pvpanic",
@@ -44,7 +44,7 @@
static void
pvpanic_send_event(unsigned int event)
{
- outb(event, port);
+ iowrite8(event, base);
}
static int
@@ -64,12 +64,19 @@
static acpi_status
pvpanic_walk_resources(struct acpi_resource *res, void *context)
{
+ struct acpi_resource_fixed_memory32 *fixmem32;
+
switch (res->type) {
case ACPI_RESOURCE_TYPE_END_TAG:
return AE_OK;
case ACPI_RESOURCE_TYPE_IO:
- port = res->data.io.minimum;
+ base = (void __iomem *) ioport_map(res->data.io.minimum, 1);
+ return AE_OK;
+
+ case ACPI_RESOURCE_TYPE_FIXED_MEMORY32:
+ fixmem32 = >data.fixed_memory32;
+ base = ioremap(fixmem32->address, fixmem32->address_length);
return AE_OK;
default:
@@ -91,7 +98,7 @@ static int pvpanic_add(struct acpi_device *device)
acpi_walk_resources(device->handle, METHOD_NAME__CRS,
pvpanic_walk_resources, NULL);
- if (!port)
+ if (!base)
return -ENODEV;
atomic_notifier_chain_register(_notifier_list,
@@ -105,6 +112,9 @@ static int pvpanic_remove(struct acpi_device *device)
atomic_notifier_chain_unregister(_notifier_list,
_panic_nb);
+
+ iounmap(base);
+
return 0;
}
--
1.8.3.1
[git pull] m68knommu fix for v4.20
Hi Linus, Can you please pull the m68knommu git tree, for-next branch. Only a single change to fix an out of bounds array access when parsing boot command line. Regards Greg The following changes since commit 35a7f35ad1b150ddf59a41dcac7b2fa32982be0e: Linux 4.19-rc8 (2018-10-15 07:20:24 +0200) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git for-next for you to fetch changes up to 381fdd62c38344a771aed06adaf14aae65c47454: m68k: fix command-line parsing when passed from u-boot (2018-10-16 09:46:02 +1000) Angelo Dureghello (1): m68k: fix command-line parsing when passed from u-boot arch/m68k/kernel/uboot.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Re: [GIT] Networking
On Sun, Oct 28, 2018 at 7:46 PM David Miller wrote: > > Please pull, thanks a lot! Pulled, Linus
[git pull] m68knommu fix for v4.20
Hi Linus, Can you please pull the m68knommu git tree, for-next branch. Only a single change to fix an out of bounds array access when parsing boot command line. Regards Greg The following changes since commit 35a7f35ad1b150ddf59a41dcac7b2fa32982be0e: Linux 4.19-rc8 (2018-10-15 07:20:24 +0200) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git for-next for you to fetch changes up to 381fdd62c38344a771aed06adaf14aae65c47454: m68k: fix command-line parsing when passed from u-boot (2018-10-16 09:46:02 +1000) Angelo Dureghello (1): m68k: fix command-line parsing when passed from u-boot arch/m68k/kernel/uboot.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Re: [GIT] Networking
On Sun, Oct 28, 2018 at 7:46 PM David Miller wrote: > > Please pull, thanks a lot! Pulled, Linus
[PATCH v2 12/12] w1: fix typo in comment
Signed-off-by: Steffen Vogel --- drivers/w1/w1.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c index 1326bd52888a..94747eeff0fa 100644 --- a/drivers/w1/w1.c +++ b/drivers/w1/w1.c @@ -1196,7 +1196,7 @@ int w1_process(void *data) __set_current_state(TASK_INTERRUPTIBLE); - /* hold list_mutex until after interruptible to prevent loosing + /* hold list_mutex until after interruptible to prevent losing * the wakeup signal when async_cmd is added. */ mutex_unlock(>list_mutex); -- 2.11.0
[PATCH v2 12/12] w1: fix typo in comment
Signed-off-by: Steffen Vogel --- drivers/w1/w1.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c index 1326bd52888a..94747eeff0fa 100644 --- a/drivers/w1/w1.c +++ b/drivers/w1/w1.c @@ -1196,7 +1196,7 @@ int w1_process(void *data) __set_current_state(TASK_INTERRUPTIBLE); - /* hold list_mutex until after interruptible to prevent loosing + /* hold list_mutex until after interruptible to prevent losing * the wakeup signal when async_cmd is added. */ mutex_unlock(>list_mutex); -- 2.11.0
[PATCH v2 08/12] w1: improve code-style of struct declarations
Among improving the readability of the struct declarations,
this fixes a warning about incorrect brace placement
raised by the checkpatch tool.
Signed-off-by: Steffen Vogel
---
drivers/w1/w1_netlink.h | 28 +---
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/drivers/w1/w1_netlink.h b/drivers/w1/w1_netlink.h
index 08cbf08f3649..7873eb54352e 100644
--- a/drivers/w1/w1_netlink.h
+++ b/drivers/w1/w1_netlink.h
@@ -61,19 +61,18 @@ enum w1_netlink_message_types {
* The netlink connector data sequence is, struct nlmsghdr, struct cn_msg,
* then one or more struct w1_netlink_msg (each with optional data).
*/
-struct w1_netlink_msg
-{
- __u8type;
- __u8status;
- __u16 len;
+struct w1_netlink_msg {
+ __u8 type;
+ __u8 status;
+ __u16 len;
union {
- __u8id[8];
+ __u8 id[8];
struct w1_mst {
- __u32 id;
- __u32 res;
+ __u32 id;
+ __u32 res;
} mst;
} id;
- __u8data[0];
+ __u8 data[0];
};
/**
@@ -117,12 +116,11 @@ enum w1_commands {
* One or more struct w1_netlink_cmd is placed starting at w1_netlink_msg.data
* each with optional data.
*/
-struct w1_netlink_cmd
-{
- __u8cmd;
- __u8res;
- __u16 len;
- __u8data[0];
+struct w1_netlink_cmd {
+ __u8 cmd;
+ __u8 res;
+ __u16 len;
+ __u8 data[0];
};
#ifdef __KERNEL__
--
2.11.0
[PATCH v2 08/12] w1: improve code-style of struct declarations
Among improving the readability of the struct declarations,
this fixes a warning about incorrect brace placement
raised by the checkpatch tool.
Signed-off-by: Steffen Vogel
---
drivers/w1/w1_netlink.h | 28 +---
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/drivers/w1/w1_netlink.h b/drivers/w1/w1_netlink.h
index 08cbf08f3649..7873eb54352e 100644
--- a/drivers/w1/w1_netlink.h
+++ b/drivers/w1/w1_netlink.h
@@ -61,19 +61,18 @@ enum w1_netlink_message_types {
* The netlink connector data sequence is, struct nlmsghdr, struct cn_msg,
* then one or more struct w1_netlink_msg (each with optional data).
*/
-struct w1_netlink_msg
-{
- __u8type;
- __u8status;
- __u16 len;
+struct w1_netlink_msg {
+ __u8 type;
+ __u8 status;
+ __u16 len;
union {
- __u8id[8];
+ __u8 id[8];
struct w1_mst {
- __u32 id;
- __u32 res;
+ __u32 id;
+ __u32 res;
} mst;
} id;
- __u8data[0];
+ __u8 data[0];
};
/**
@@ -117,12 +116,11 @@ enum w1_commands {
* One or more struct w1_netlink_cmd is placed starting at w1_netlink_msg.data
* each with optional data.
*/
-struct w1_netlink_cmd
-{
- __u8cmd;
- __u8res;
- __u16 len;
- __u8data[0];
+struct w1_netlink_cmd {
+ __u8 cmd;
+ __u8 res;
+ __u16 len;
+ __u8 data[0];
};
#ifdef __KERNEL__
--
2.11.0
[PATCH v2 00/11] w1: coding style and checkpatch fixes
Hi, This is my first series of patches for the Linux kernel. I started by familiarizing myself with coding style and satisfying my inner OCD by cleaning the 1-wire subsystem. Cheers, Steffen --- Changes since v1: - addressed comments from Joe Perches: - re-ran checkpatch.pl in --strict mode - fixed commit messages to reflect more precisly the checkpatch warnings Steffen Vogel (12): w1: add SPDX identifiers w1: improve code-style by adhering tp 80 columns per line limit w1: add newlines after declarations w1: cleanup whitespaces according to coding style document w1: use octal numbers instead of macros for file mode w1: do not log errors about failed memory allocations w1: use __func__ for logging the function name w1: improve code-style of struct declarations w1: using linux instead of asm prefix for includes w1: use pointers instead of types to determine size of allocs w1: replace non-standard %LX format-string by %llX w1: fix typo in comment drivers/w1/masters/ds1wm.c | 5 +- drivers/w1/masters/ds2482.c| 7 +- drivers/w1/masters/ds2490.c| 16 +-- drivers/w1/masters/matrox_w1.c | 16 +-- drivers/w1/masters/mxc_w1.c| 10 +- drivers/w1/masters/omap_hdq.c | 7 +- drivers/w1/masters/w1-gpio.c | 5 +- drivers/w1/slaves/w1_ds2405.c | 12 +- drivers/w1/slaves/w1_ds2406.c | 4 +- drivers/w1/slaves/w1_ds2408.c | 4 +- drivers/w1/slaves/w1_ds2413.c | 4 +- drivers/w1/slaves/w1_ds2423.c | 15 +-- drivers/w1/slaves/w1_ds2431.c | 4 +- drivers/w1/slaves/w1_ds2433.c | 4 +- drivers/w1/slaves/w1_ds2438.c | 4 +- drivers/w1/slaves/w1_ds2780.c | 6 +- drivers/w1/slaves/w1_ds2781.c | 6 +- drivers/w1/slaves/w1_ds2805.c | 4 +- drivers/w1/slaves/w1_ds28e04.c | 4 +- drivers/w1/slaves/w1_ds28e17.c | 4 +- drivers/w1/slaves/w1_smem.c| 16 +-- drivers/w1/slaves/w1_therm.c | 16 +-- drivers/w1/w1.c| 272 +++-- drivers/w1/w1_family.c | 15 +-- drivers/w1/w1_int.c| 34 ++ drivers/w1/w1_internal.h | 11 +- drivers/w1/w1_io.c | 86 ++--- drivers/w1/w1_netlink.c| 64 +- drivers/w1/w1_netlink.h| 39 +++--- 29 files changed, 283 insertions(+), 411 deletions(-) -- 2.11.0
[PATCH v2 10/12] w1: use pointers instead of types to determine size of allocs
Get size of allocation based on pointer not type. Signed-off-by: Steffen Vogel --- drivers/w1/w1.c | 2 +- drivers/w1/w1_int.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c index 4cbe1849fbfc..87094d99ccbe 100644 --- a/drivers/w1/w1.c +++ b/drivers/w1/w1.c @@ -756,7 +756,7 @@ int w1_attach_slave_device(struct w1_master *dev, struct w1_reg_num *rn) int err; struct w1_netlink_msg msg; - sl = kzalloc(sizeof(struct w1_slave), GFP_KERNEL); + sl = kzalloc(sizeof(*sl), GFP_KERNEL); if (!sl) return -ENOMEM; diff --git a/drivers/w1/w1_int.c b/drivers/w1/w1_int.c index a5230c0d49e3..2bf7631ac24f 100644 --- a/drivers/w1/w1_int.c +++ b/drivers/w1/w1_int.c @@ -31,7 +31,7 @@ static struct w1_master *w1_alloc_dev(u32 id, int slave_count, int slave_ttl, /* * We are in process context(kernel thread), so can sleep. */ - dev = kzalloc(sizeof(struct w1_master) + + dev = kzalloc(sizeof(*dev) + sizeof(struct w1_bus_master), GFP_KERNEL); if (!dev) return NULL; -- 2.11.0
[PATCH v2 00/11] w1: coding style and checkpatch fixes
Hi, This is my first series of patches for the Linux kernel. I started by familiarizing myself with coding style and satisfying my inner OCD by cleaning the 1-wire subsystem. Cheers, Steffen --- Changes since v1: - addressed comments from Joe Perches: - re-ran checkpatch.pl in --strict mode - fixed commit messages to reflect more precisly the checkpatch warnings Steffen Vogel (12): w1: add SPDX identifiers w1: improve code-style by adhering tp 80 columns per line limit w1: add newlines after declarations w1: cleanup whitespaces according to coding style document w1: use octal numbers instead of macros for file mode w1: do not log errors about failed memory allocations w1: use __func__ for logging the function name w1: improve code-style of struct declarations w1: using linux instead of asm prefix for includes w1: use pointers instead of types to determine size of allocs w1: replace non-standard %LX format-string by %llX w1: fix typo in comment drivers/w1/masters/ds1wm.c | 5 +- drivers/w1/masters/ds2482.c| 7 +- drivers/w1/masters/ds2490.c| 16 +-- drivers/w1/masters/matrox_w1.c | 16 +-- drivers/w1/masters/mxc_w1.c| 10 +- drivers/w1/masters/omap_hdq.c | 7 +- drivers/w1/masters/w1-gpio.c | 5 +- drivers/w1/slaves/w1_ds2405.c | 12 +- drivers/w1/slaves/w1_ds2406.c | 4 +- drivers/w1/slaves/w1_ds2408.c | 4 +- drivers/w1/slaves/w1_ds2413.c | 4 +- drivers/w1/slaves/w1_ds2423.c | 15 +-- drivers/w1/slaves/w1_ds2431.c | 4 +- drivers/w1/slaves/w1_ds2433.c | 4 +- drivers/w1/slaves/w1_ds2438.c | 4 +- drivers/w1/slaves/w1_ds2780.c | 6 +- drivers/w1/slaves/w1_ds2781.c | 6 +- drivers/w1/slaves/w1_ds2805.c | 4 +- drivers/w1/slaves/w1_ds28e04.c | 4 +- drivers/w1/slaves/w1_ds28e17.c | 4 +- drivers/w1/slaves/w1_smem.c| 16 +-- drivers/w1/slaves/w1_therm.c | 16 +-- drivers/w1/w1.c| 272 +++-- drivers/w1/w1_family.c | 15 +-- drivers/w1/w1_int.c| 34 ++ drivers/w1/w1_internal.h | 11 +- drivers/w1/w1_io.c | 86 ++--- drivers/w1/w1_netlink.c| 64 +- drivers/w1/w1_netlink.h| 39 +++--- 29 files changed, 283 insertions(+), 411 deletions(-) -- 2.11.0
[PATCH v2 10/12] w1: use pointers instead of types to determine size of allocs
Get size of allocation based on pointer not type. Signed-off-by: Steffen Vogel --- drivers/w1/w1.c | 2 +- drivers/w1/w1_int.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c index 4cbe1849fbfc..87094d99ccbe 100644 --- a/drivers/w1/w1.c +++ b/drivers/w1/w1.c @@ -756,7 +756,7 @@ int w1_attach_slave_device(struct w1_master *dev, struct w1_reg_num *rn) int err; struct w1_netlink_msg msg; - sl = kzalloc(sizeof(struct w1_slave), GFP_KERNEL); + sl = kzalloc(sizeof(*sl), GFP_KERNEL); if (!sl) return -ENOMEM; diff --git a/drivers/w1/w1_int.c b/drivers/w1/w1_int.c index a5230c0d49e3..2bf7631ac24f 100644 --- a/drivers/w1/w1_int.c +++ b/drivers/w1/w1_int.c @@ -31,7 +31,7 @@ static struct w1_master *w1_alloc_dev(u32 id, int slave_count, int slave_ttl, /* * We are in process context(kernel thread), so can sleep. */ - dev = kzalloc(sizeof(struct w1_master) + + dev = kzalloc(sizeof(*dev) + sizeof(struct w1_bus_master), GFP_KERNEL); if (!dev) return NULL; -- 2.11.0
[PATCH v2 03/12] w1: add newlines after declarations
This satisfies a checkpatch warning
Signed-off-by: Steffen Vogel
---
drivers/w1/w1.c | 23 +++
drivers/w1/w1_netlink.c | 7 +++
2 files changed, 30 insertions(+)
diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
index 6b3cdc5a09fb..48c20639f75f 100644
--- a/drivers/w1/w1.c
+++ b/drivers/w1/w1.c
@@ -128,6 +128,7 @@ static ssize_t rw_write(struct file *filp, struct kobject
*kobj,
out_up:
mutex_unlock(>master->mutex);
+
return count;
}
@@ -140,6 +141,7 @@ static ssize_t rw_read(struct file *filp, struct kobject
*kobj,
mutex_lock(>master->mutex);
w1_read_block(sl->master, buf, count);
mutex_unlock(>master->mutex);
+
return count;
}
@@ -296,6 +298,7 @@ static ssize_t w1_master_attribute_show_pointer(struct
device *dev,
mutex_lock(>mutex);
count = sprintf(buf, "0x%p\n", md->bus_master);
mutex_unlock(>mutex);
+
return count;
}
@@ -304,7 +307,9 @@ static ssize_t w1_master_attribute_show_timeout(struct
device *dev,
char *buf)
{
ssize_t count;
+
count = sprintf(buf, "%d\n", w1_timeout);
+
return count;
}
@@ -313,7 +318,9 @@ static ssize_t w1_master_attribute_show_timeout_us(struct
device *dev,
char *buf)
{
ssize_t count;
+
count = sprintf(buf, "%d\n", w1_timeout_us);
+
return count;
}
@@ -375,6 +382,7 @@ static ssize_t w1_master_attribute_show_slave_count(struct
device *dev,
mutex_lock(>mutex);
count = sprintf(buf, "%d\n", md->slave_count);
mutex_unlock(>mutex);
+
return count;
}
@@ -407,8 +415,10 @@ static ssize_t w1_master_attribute_show_add(struct device
*dev,
char *buf)
{
int c = PAGE_SIZE;
+
c -= snprintf(buf+PAGE_SIZE - c, c,
"write device id xx- to add slave\n");
+
return PAGE_SIZE - c;
}
@@ -457,6 +467,7 @@ struct w1_slave *w1_slave_search_device(struct w1_master
*dev,
struct w1_reg_num *rn)
{
struct w1_slave *sl;
+
mutex_lock(>list_mutex);
list_for_each_entry(sl, >slist, w1_slave_entry) {
if (sl->reg_num.family == rn->family &&
@@ -467,6 +478,7 @@ struct w1_slave *w1_slave_search_device(struct w1_master
*dev,
}
}
mutex_unlock(>list_mutex);
+
return NULL;
}
@@ -504,8 +516,10 @@ static ssize_t w1_master_attribute_show_remove(struct
device *dev,
char *buf)
{
int c = PAGE_SIZE;
+
c -= snprintf(buf+PAGE_SIZE - c, c,
"write device id xx- to remove slave\n");
+
return PAGE_SIZE - c;
}
@@ -684,6 +698,7 @@ static int w1_family_notify(unsigned long action, struct
w1_slave *sl)
sysfs_remove_groups(>dev.kobj, fops->groups);
break;
}
+
return 0;
}
@@ -719,6 +734,7 @@ static int __w1_attach_slave_device(struct w1_slave *sl)
"Device registration [%s] failed. err=%d\n",
dev_name(>dev), err);
put_device(>dev);
+
return err;
}
w1_family_notify(BUS_NOTIFY_ADD_DEVICE, sl);
@@ -787,6 +803,7 @@ int w1_attach_slave_device(struct w1_master *dev, struct
w1_reg_num *rn)
w1_family_put(sl->family);
atomic_dec(>master->refcnt);
kfree(sl);
+
return err;
}
@@ -803,6 +820,7 @@ int w1_unref_slave(struct w1_slave *sl)
{
struct w1_master *dev = sl->master;
int refcnt;
+
mutex_lock(>list_mutex);
refcnt = atomic_sub_return(1, >refcnt);
if (refcnt == 0) {
@@ -827,6 +845,7 @@ int w1_unref_slave(struct w1_slave *sl)
}
atomic_dec(>refcnt);
mutex_unlock(>list_mutex);
+
return refcnt;
}
@@ -834,6 +853,7 @@ int w1_slave_detach(struct w1_slave *sl)
{
/* Only detach a slave once as it decreases the refcnt each time. */
int destroy_now;
+
mutex_lock(>master->list_mutex);
destroy_now = !test_bit(W1_SLAVE_DETACH, >flags);
set_bit(W1_SLAVE_DETACH, >flags);
@@ -841,6 +861,7 @@ int w1_slave_detach(struct w1_slave *sl)
if (destroy_now)
destroy_now = !w1_unref_slave(sl);
+
return destroy_now ? 0 : -EBUSY;
}
@@ -1006,6 +1027,7 @@ void w1_search(struct w1_master *dev, u8 search_type,
/* Do fast search on single slave bus */
if (dev->max_slave_count == 1) {
int rv;
+
w1_write_8(dev, W1_READ_ROM);
rv = w1_read_block(dev, (u8 *), 8);
mutex_unlock(>bus_mutex);
@@ -1141,6 +1163,7 @@ int w1_process_callbacks(struct
[PATCH v2 03/12] w1: add newlines after declarations
This satisfies a checkpatch warning
Signed-off-by: Steffen Vogel
---
drivers/w1/w1.c | 23 +++
drivers/w1/w1_netlink.c | 7 +++
2 files changed, 30 insertions(+)
diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
index 6b3cdc5a09fb..48c20639f75f 100644
--- a/drivers/w1/w1.c
+++ b/drivers/w1/w1.c
@@ -128,6 +128,7 @@ static ssize_t rw_write(struct file *filp, struct kobject
*kobj,
out_up:
mutex_unlock(>master->mutex);
+
return count;
}
@@ -140,6 +141,7 @@ static ssize_t rw_read(struct file *filp, struct kobject
*kobj,
mutex_lock(>master->mutex);
w1_read_block(sl->master, buf, count);
mutex_unlock(>master->mutex);
+
return count;
}
@@ -296,6 +298,7 @@ static ssize_t w1_master_attribute_show_pointer(struct
device *dev,
mutex_lock(>mutex);
count = sprintf(buf, "0x%p\n", md->bus_master);
mutex_unlock(>mutex);
+
return count;
}
@@ -304,7 +307,9 @@ static ssize_t w1_master_attribute_show_timeout(struct
device *dev,
char *buf)
{
ssize_t count;
+
count = sprintf(buf, "%d\n", w1_timeout);
+
return count;
}
@@ -313,7 +318,9 @@ static ssize_t w1_master_attribute_show_timeout_us(struct
device *dev,
char *buf)
{
ssize_t count;
+
count = sprintf(buf, "%d\n", w1_timeout_us);
+
return count;
}
@@ -375,6 +382,7 @@ static ssize_t w1_master_attribute_show_slave_count(struct
device *dev,
mutex_lock(>mutex);
count = sprintf(buf, "%d\n", md->slave_count);
mutex_unlock(>mutex);
+
return count;
}
@@ -407,8 +415,10 @@ static ssize_t w1_master_attribute_show_add(struct device
*dev,
char *buf)
{
int c = PAGE_SIZE;
+
c -= snprintf(buf+PAGE_SIZE - c, c,
"write device id xx- to add slave\n");
+
return PAGE_SIZE - c;
}
@@ -457,6 +467,7 @@ struct w1_slave *w1_slave_search_device(struct w1_master
*dev,
struct w1_reg_num *rn)
{
struct w1_slave *sl;
+
mutex_lock(>list_mutex);
list_for_each_entry(sl, >slist, w1_slave_entry) {
if (sl->reg_num.family == rn->family &&
@@ -467,6 +478,7 @@ struct w1_slave *w1_slave_search_device(struct w1_master
*dev,
}
}
mutex_unlock(>list_mutex);
+
return NULL;
}
@@ -504,8 +516,10 @@ static ssize_t w1_master_attribute_show_remove(struct
device *dev,
char *buf)
{
int c = PAGE_SIZE;
+
c -= snprintf(buf+PAGE_SIZE - c, c,
"write device id xx- to remove slave\n");
+
return PAGE_SIZE - c;
}
@@ -684,6 +698,7 @@ static int w1_family_notify(unsigned long action, struct
w1_slave *sl)
sysfs_remove_groups(>dev.kobj, fops->groups);
break;
}
+
return 0;
}
@@ -719,6 +734,7 @@ static int __w1_attach_slave_device(struct w1_slave *sl)
"Device registration [%s] failed. err=%d\n",
dev_name(>dev), err);
put_device(>dev);
+
return err;
}
w1_family_notify(BUS_NOTIFY_ADD_DEVICE, sl);
@@ -787,6 +803,7 @@ int w1_attach_slave_device(struct w1_master *dev, struct
w1_reg_num *rn)
w1_family_put(sl->family);
atomic_dec(>master->refcnt);
kfree(sl);
+
return err;
}
@@ -803,6 +820,7 @@ int w1_unref_slave(struct w1_slave *sl)
{
struct w1_master *dev = sl->master;
int refcnt;
+
mutex_lock(>list_mutex);
refcnt = atomic_sub_return(1, >refcnt);
if (refcnt == 0) {
@@ -827,6 +845,7 @@ int w1_unref_slave(struct w1_slave *sl)
}
atomic_dec(>refcnt);
mutex_unlock(>list_mutex);
+
return refcnt;
}
@@ -834,6 +853,7 @@ int w1_slave_detach(struct w1_slave *sl)
{
/* Only detach a slave once as it decreases the refcnt each time. */
int destroy_now;
+
mutex_lock(>master->list_mutex);
destroy_now = !test_bit(W1_SLAVE_DETACH, >flags);
set_bit(W1_SLAVE_DETACH, >flags);
@@ -841,6 +861,7 @@ int w1_slave_detach(struct w1_slave *sl)
if (destroy_now)
destroy_now = !w1_unref_slave(sl);
+
return destroy_now ? 0 : -EBUSY;
}
@@ -1006,6 +1027,7 @@ void w1_search(struct w1_master *dev, u8 search_type,
/* Do fast search on single slave bus */
if (dev->max_slave_count == 1) {
int rv;
+
w1_write_8(dev, W1_READ_ROM);
rv = w1_read_block(dev, (u8 *), 8);
mutex_unlock(>bus_mutex);
@@ -1141,6 +1163,7 @@ int w1_process_callbacks(struct
[PATCH v2 01/12] w1: add SPDX identifiers
This satisfies a checkpatch warning and is the preferred method for notating the license. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. Signed-off-by: Steffen Vogel --- drivers/w1/masters/ds1wm.c | 5 + drivers/w1/masters/ds2482.c| 7 ++- drivers/w1/masters/ds2490.c| 16 +--- drivers/w1/masters/matrox_w1.c | 16 +--- drivers/w1/masters/mxc_w1.c| 10 +- drivers/w1/masters/omap_hdq.c | 7 ++- drivers/w1/masters/w1-gpio.c | 5 + drivers/w1/slaves/w1_ds2405.c | 12 +--- drivers/w1/slaves/w1_ds2406.c | 4 +--- drivers/w1/slaves/w1_ds2408.c | 4 +--- drivers/w1/slaves/w1_ds2413.c | 4 +--- drivers/w1/slaves/w1_ds2423.c | 15 +-- drivers/w1/slaves/w1_ds2431.c | 4 +--- drivers/w1/slaves/w1_ds2433.c | 4 +--- drivers/w1/slaves/w1_ds2438.c | 4 +--- drivers/w1/slaves/w1_ds2780.c | 6 +- drivers/w1/slaves/w1_ds2781.c | 6 +- drivers/w1/slaves/w1_ds2805.c | 4 +--- drivers/w1/slaves/w1_ds28e04.c | 4 +--- drivers/w1/slaves/w1_ds28e17.c | 4 +--- drivers/w1/slaves/w1_smem.c| 16 +--- drivers/w1/slaves/w1_therm.c | 16 +--- drivers/w1/w1.c| 11 +-- drivers/w1/w1_family.c | 11 +-- drivers/w1/w1_int.c| 11 +-- drivers/w1/w1_internal.h | 11 +-- drivers/w1/w1_io.c | 11 +-- drivers/w1/w1_netlink.c| 11 +-- drivers/w1/w1_netlink.h| 11 +-- 29 files changed, 31 insertions(+), 219 deletions(-) diff --git a/drivers/w1/masters/ds1wm.c b/drivers/w1/masters/ds1wm.c index f661695fb589..83a991a3e3bd 100644 --- a/drivers/w1/masters/ds1wm.c +++ b/drivers/w1/masters/ds1wm.c @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0 /* * 1-wire busmaster driver for DS1WM and ASICs with embedded DS1WMs * such as HP iPAQs (including h5xxx, h2200, and devices with ASIC3 @@ -5,10 +6,6 @@ * * Copyright (c) 2004-2005, Szabolcs Gyurko * Copyright (c) 2004-2007, Matt Reimer - * - * Use consistent with the GNU GPL is permitted, - * provided that this copyright notice is - * preserved in its entirety in all copies and derived works. */ #include diff --git a/drivers/w1/masters/ds2482.c b/drivers/w1/masters/ds2482.c index 8b5e598ffdb3..d9bb021eca7e 100644 --- a/drivers/w1/masters/ds2482.c +++ b/drivers/w1/masters/ds2482.c @@ -1,4 +1,5 @@ -/** +// SPDX-License-Identifier: GPL-2.0 +/* * ds2482.c - provides i2c to w1-master bridge(s) * Copyright (C) 2005 Ben Gardner * @@ -7,10 +8,6 @@ * There are two variations: -100 and -800, which have 1 or 8 1-wire ports. * The complete datasheet can be obtained from MAXIM's website at: * http://www.maxim-ic.com/quick_view2.cfm/qv_pk/4382 - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; version 2 of the License. */ #include diff --git a/drivers/w1/masters/ds2490.c b/drivers/w1/masters/ds2490.c index 0f4ecfcdb549..7bd9862ef337 100644 --- a/drivers/w1/masters/ds2490.c +++ b/drivers/w1/masters/ds2490.c @@ -1,22 +1,8 @@ +// SPDX-License-Identifier: GPL-2.0+ /* * ds2490.c USB to one wire bridge * * Copyright (c) 2004 Evgeniy Polyakov - * - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include diff --git a/drivers/w1/masters/matrox_w1.c b/drivers/w1/masters/matrox_w1.c index d83d7c99d81d..be131c04ee63 100644 --- a/drivers/w1/masters/matrox_w1.c +++ b/drivers/w1/masters/matrox_w1.c @@ -1,22 +1,8 @@ +// SPDX-License-Identifier: GPL-2.0+ /* * matrox_w1.c * * Copyright (c) 2004 Evgeniy Polyakov - * - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You
[PATCH v2 04/12] w1: cleanup whitespaces according to coding style document
These changes fix several warnings emitted by the checkpatch tool.
Signed-off-by: Steffen Vogel
---
drivers/w1/w1.c | 38 +++---
drivers/w1/w1_family.c | 2 +-
drivers/w1/w1_io.c | 40 +---
drivers/w1/w1_netlink.c | 8
4 files changed, 45 insertions(+), 43 deletions(-)
diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
index 48c20639f75f..184df1fe216b 100644
--- a/drivers/w1/w1.c
+++ b/drivers/w1/w1.c
@@ -416,7 +416,7 @@ static ssize_t w1_master_attribute_show_add(struct device
*dev,
{
int c = PAGE_SIZE;
- c -= snprintf(buf+PAGE_SIZE - c, c,
+ c -= snprintf(buf + PAGE_SIZE - c, c,
"write device id xx- to add slave\n");
return PAGE_SIZE - c;
@@ -517,7 +517,7 @@ static ssize_t w1_master_attribute_show_remove(struct
device *dev,
{
int c = PAGE_SIZE;
- c -= snprintf(buf+PAGE_SIZE - c, c,
+ c -= snprintf(buf + PAGE_SIZE - c, c,
"write device id xx- to remove slave\n");
return PAGE_SIZE - c;
@@ -785,7 +785,7 @@ int w1_attach_slave_device(struct w1_master *dev, struct
w1_reg_num *rn)
spin_lock(_flock);
f = w1_family_registered(rn->family);
if (!f) {
- f= _default_family;
+ f = _default_family;
dev_info(>dev, "Family %x for %02x.%012llx.%02x is not
registered.\n",
rn->family, rn->family,
(unsigned long long)rn->id, rn->crc);
@@ -880,7 +880,7 @@ struct w1_master *w1_search_master_id(u32 id)
}
mutex_unlock(_mlock);
- return (found)?dev:NULL;
+ return found ? dev : NULL;
}
struct w1_slave *w1_search_slave(struct w1_reg_num *id)
@@ -909,7 +909,7 @@ struct w1_slave *w1_search_slave(struct w1_reg_num *id)
}
mutex_unlock(_mlock);
- return (found)?sl:NULL;
+ return found ? sl : NULL;
}
void w1_reconnect_slaves(struct w1_family *f, int attach)
@@ -960,7 +960,7 @@ void w1_slave_found(struct w1_master *dev, u64 rn)
atomic_inc(>refcnt);
- tmp = (struct w1_reg_num *)
+ tmp = (struct w1_reg_num *)
sl = w1_slave_search_device(dev, tmp);
if (sl) {
@@ -1007,12 +1007,11 @@ void w1_search(struct w1_master *dev, u8 search_type,
desc_bit = 64;
- while ( !last_device && (slave_count++ < dev->max_slave_count) ) {
+ while (!last_device && (slave_count++ < dev->max_slave_count)) {
last_rn = rn;
rn = 0;
- /*
-* Reset bus and all 1-wire device state machines
+ /* Reset bus and all 1-wire device state machines
* so they can respond to our requests.
*
* Return 0 - device(s) present, 1 - no devices present.
@@ -1059,7 +1058,7 @@ void w1_search(struct w1_master *dev, u8 search_type,
triplet_ret = w1_triplet(dev, search_bit);
/* quit if no device responded */
- if ( (triplet_ret & 0x03) == 0x03 )
+ if ((triplet_ret & 0x03) == 0x03)
break;
/* If both directions were valid, and we took the 0
path */
@@ -1078,13 +1077,14 @@ void w1_search(struct w1_master *dev, u8 search_type,
}
mutex_unlock(>bus_mutex);
- if ( (triplet_ret & 0x03) != 0x03 ) {
- if ((desc_bit == last_zero) || (last_zero < 0)) {
+ if ((triplet_ret & 0x03) != 0x03) {
+ if (desc_bit == last_zero || last_zero < 0) {
last_device = 1;
dev->search_id = 0;
} else {
dev->search_id = rn;
}
+
desc_bit = last_zero;
cb(dev, rn);
}
@@ -1123,9 +1123,9 @@ void w1_search_process_cb(struct w1_master *dev, u8
search_type,
mutex_unlock(>list_mutex);
w1_slave_detach(sl);
mutex_lock(>list_mutex);
- }
- else if (test_bit(W1_SLAVE_ACTIVE, >flags))
+ } else if (test_bit(W1_SLAVE_ACTIVE, >flags)) {
sl->ttl = dev->slave_ttl;
+ }
}
mutex_unlock(>list_mutex);
@@ -1156,7 +1156,8 @@ int w1_process_callbacks(struct w1_master *dev)
list_for_each_entry_safe(async_cmd, async_n, >async_list,
async_entry) {
/* drop the lock, if it is a search it can take a long
-* time */
+* time
+*/
mutex_unlock(>list_mutex);
[PATCH v2 01/12] w1: add SPDX identifiers
This satisfies a checkpatch warning and is the preferred method for notating the license. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. Signed-off-by: Steffen Vogel --- drivers/w1/masters/ds1wm.c | 5 + drivers/w1/masters/ds2482.c| 7 ++- drivers/w1/masters/ds2490.c| 16 +--- drivers/w1/masters/matrox_w1.c | 16 +--- drivers/w1/masters/mxc_w1.c| 10 +- drivers/w1/masters/omap_hdq.c | 7 ++- drivers/w1/masters/w1-gpio.c | 5 + drivers/w1/slaves/w1_ds2405.c | 12 +--- drivers/w1/slaves/w1_ds2406.c | 4 +--- drivers/w1/slaves/w1_ds2408.c | 4 +--- drivers/w1/slaves/w1_ds2413.c | 4 +--- drivers/w1/slaves/w1_ds2423.c | 15 +-- drivers/w1/slaves/w1_ds2431.c | 4 +--- drivers/w1/slaves/w1_ds2433.c | 4 +--- drivers/w1/slaves/w1_ds2438.c | 4 +--- drivers/w1/slaves/w1_ds2780.c | 6 +- drivers/w1/slaves/w1_ds2781.c | 6 +- drivers/w1/slaves/w1_ds2805.c | 4 +--- drivers/w1/slaves/w1_ds28e04.c | 4 +--- drivers/w1/slaves/w1_ds28e17.c | 4 +--- drivers/w1/slaves/w1_smem.c| 16 +--- drivers/w1/slaves/w1_therm.c | 16 +--- drivers/w1/w1.c| 11 +-- drivers/w1/w1_family.c | 11 +-- drivers/w1/w1_int.c| 11 +-- drivers/w1/w1_internal.h | 11 +-- drivers/w1/w1_io.c | 11 +-- drivers/w1/w1_netlink.c| 11 +-- drivers/w1/w1_netlink.h| 11 +-- 29 files changed, 31 insertions(+), 219 deletions(-) diff --git a/drivers/w1/masters/ds1wm.c b/drivers/w1/masters/ds1wm.c index f661695fb589..83a991a3e3bd 100644 --- a/drivers/w1/masters/ds1wm.c +++ b/drivers/w1/masters/ds1wm.c @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0 /* * 1-wire busmaster driver for DS1WM and ASICs with embedded DS1WMs * such as HP iPAQs (including h5xxx, h2200, and devices with ASIC3 @@ -5,10 +6,6 @@ * * Copyright (c) 2004-2005, Szabolcs Gyurko * Copyright (c) 2004-2007, Matt Reimer - * - * Use consistent with the GNU GPL is permitted, - * provided that this copyright notice is - * preserved in its entirety in all copies and derived works. */ #include diff --git a/drivers/w1/masters/ds2482.c b/drivers/w1/masters/ds2482.c index 8b5e598ffdb3..d9bb021eca7e 100644 --- a/drivers/w1/masters/ds2482.c +++ b/drivers/w1/masters/ds2482.c @@ -1,4 +1,5 @@ -/** +// SPDX-License-Identifier: GPL-2.0 +/* * ds2482.c - provides i2c to w1-master bridge(s) * Copyright (C) 2005 Ben Gardner * @@ -7,10 +8,6 @@ * There are two variations: -100 and -800, which have 1 or 8 1-wire ports. * The complete datasheet can be obtained from MAXIM's website at: * http://www.maxim-ic.com/quick_view2.cfm/qv_pk/4382 - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; version 2 of the License. */ #include diff --git a/drivers/w1/masters/ds2490.c b/drivers/w1/masters/ds2490.c index 0f4ecfcdb549..7bd9862ef337 100644 --- a/drivers/w1/masters/ds2490.c +++ b/drivers/w1/masters/ds2490.c @@ -1,22 +1,8 @@ +// SPDX-License-Identifier: GPL-2.0+ /* * ds2490.c USB to one wire bridge * * Copyright (c) 2004 Evgeniy Polyakov - * - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include diff --git a/drivers/w1/masters/matrox_w1.c b/drivers/w1/masters/matrox_w1.c index d83d7c99d81d..be131c04ee63 100644 --- a/drivers/w1/masters/matrox_w1.c +++ b/drivers/w1/masters/matrox_w1.c @@ -1,22 +1,8 @@ +// SPDX-License-Identifier: GPL-2.0+ /* * matrox_w1.c * * Copyright (c) 2004 Evgeniy Polyakov - * - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You
[PATCH v2 04/12] w1: cleanup whitespaces according to coding style document
These changes fix several warnings emitted by the checkpatch tool.
Signed-off-by: Steffen Vogel
---
drivers/w1/w1.c | 38 +++---
drivers/w1/w1_family.c | 2 +-
drivers/w1/w1_io.c | 40 +---
drivers/w1/w1_netlink.c | 8
4 files changed, 45 insertions(+), 43 deletions(-)
diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
index 48c20639f75f..184df1fe216b 100644
--- a/drivers/w1/w1.c
+++ b/drivers/w1/w1.c
@@ -416,7 +416,7 @@ static ssize_t w1_master_attribute_show_add(struct device
*dev,
{
int c = PAGE_SIZE;
- c -= snprintf(buf+PAGE_SIZE - c, c,
+ c -= snprintf(buf + PAGE_SIZE - c, c,
"write device id xx- to add slave\n");
return PAGE_SIZE - c;
@@ -517,7 +517,7 @@ static ssize_t w1_master_attribute_show_remove(struct
device *dev,
{
int c = PAGE_SIZE;
- c -= snprintf(buf+PAGE_SIZE - c, c,
+ c -= snprintf(buf + PAGE_SIZE - c, c,
"write device id xx- to remove slave\n");
return PAGE_SIZE - c;
@@ -785,7 +785,7 @@ int w1_attach_slave_device(struct w1_master *dev, struct
w1_reg_num *rn)
spin_lock(_flock);
f = w1_family_registered(rn->family);
if (!f) {
- f= _default_family;
+ f = _default_family;
dev_info(>dev, "Family %x for %02x.%012llx.%02x is not
registered.\n",
rn->family, rn->family,
(unsigned long long)rn->id, rn->crc);
@@ -880,7 +880,7 @@ struct w1_master *w1_search_master_id(u32 id)
}
mutex_unlock(_mlock);
- return (found)?dev:NULL;
+ return found ? dev : NULL;
}
struct w1_slave *w1_search_slave(struct w1_reg_num *id)
@@ -909,7 +909,7 @@ struct w1_slave *w1_search_slave(struct w1_reg_num *id)
}
mutex_unlock(_mlock);
- return (found)?sl:NULL;
+ return found ? sl : NULL;
}
void w1_reconnect_slaves(struct w1_family *f, int attach)
@@ -960,7 +960,7 @@ void w1_slave_found(struct w1_master *dev, u64 rn)
atomic_inc(>refcnt);
- tmp = (struct w1_reg_num *)
+ tmp = (struct w1_reg_num *)
sl = w1_slave_search_device(dev, tmp);
if (sl) {
@@ -1007,12 +1007,11 @@ void w1_search(struct w1_master *dev, u8 search_type,
desc_bit = 64;
- while ( !last_device && (slave_count++ < dev->max_slave_count) ) {
+ while (!last_device && (slave_count++ < dev->max_slave_count)) {
last_rn = rn;
rn = 0;
- /*
-* Reset bus and all 1-wire device state machines
+ /* Reset bus and all 1-wire device state machines
* so they can respond to our requests.
*
* Return 0 - device(s) present, 1 - no devices present.
@@ -1059,7 +1058,7 @@ void w1_search(struct w1_master *dev, u8 search_type,
triplet_ret = w1_triplet(dev, search_bit);
/* quit if no device responded */
- if ( (triplet_ret & 0x03) == 0x03 )
+ if ((triplet_ret & 0x03) == 0x03)
break;
/* If both directions were valid, and we took the 0
path */
@@ -1078,13 +1077,14 @@ void w1_search(struct w1_master *dev, u8 search_type,
}
mutex_unlock(>bus_mutex);
- if ( (triplet_ret & 0x03) != 0x03 ) {
- if ((desc_bit == last_zero) || (last_zero < 0)) {
+ if ((triplet_ret & 0x03) != 0x03) {
+ if (desc_bit == last_zero || last_zero < 0) {
last_device = 1;
dev->search_id = 0;
} else {
dev->search_id = rn;
}
+
desc_bit = last_zero;
cb(dev, rn);
}
@@ -1123,9 +1123,9 @@ void w1_search_process_cb(struct w1_master *dev, u8
search_type,
mutex_unlock(>list_mutex);
w1_slave_detach(sl);
mutex_lock(>list_mutex);
- }
- else if (test_bit(W1_SLAVE_ACTIVE, >flags))
+ } else if (test_bit(W1_SLAVE_ACTIVE, >flags)) {
sl->ttl = dev->slave_ttl;
+ }
}
mutex_unlock(>list_mutex);
@@ -1156,7 +1156,8 @@ int w1_process_callbacks(struct w1_master *dev)
list_for_each_entry_safe(async_cmd, async_n, >async_list,
async_entry) {
/* drop the lock, if it is a search it can take a long
-* time */
+* time
+*/
mutex_unlock(>list_mutex);
[PATCH RESEND] spi: spi-fsl-dspi: use IRQF_SHARED mode to request IRQ
Some SoC share one irq number between DSPI controllers.
For example, on the LX2160 board, DSPI0 and DSPI1 share one irq number.
In this case, only one DSPI controller can register successfully,
and others will fail.
Signed-off-by: Chuanhua Han
---
drivers/spi/spi-fsl-dspi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 3082e72e4f6c..5e10dc5c93a5 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -1090,8 +1090,8 @@ static int dspi_probe(struct platform_device *pdev)
goto out_clk_put;
}
- ret = devm_request_irq(>dev, dspi->irq, dspi_interrupt, 0,
- pdev->name, dspi);
+ ret = devm_request_irq(>dev, dspi->irq, dspi_interrupt,
+ IRQF_SHARED, pdev->name, dspi);
if (ret < 0) {
dev_err(>dev, "Unable to attach DSPI interrupt\n");
goto out_clk_put;
--
2.17.1
Re: [PATCH 3/3] drm/mediatek: Use drm_gem_cma_object instead of mtk_drm_gem_obj
Hi,Daniel:
On Fri, 2018-10-26 at 12:21 +0200, Daniel Vetter wrote:
> On Fri, Oct 26, 2018 at 03:22:03PM +0800, CK Hu wrote:
> > After adding dma_dev in struct drm_device and
> > drm_gem_cma_dumb_create_no_kmap(), drm_gem_cma_object could replace
> > mtk_drm_gem_obj, so use drm_gem_cma_object instead of mtk_drm_gem_obj to
> > reduce redundant code.
> >
> > Signed-off-by: CK Hu
>
> A few questions/thoughts:
>
> - Why do you need both drm_device->dev and drm_device->dma_dev? Can't you
> just register the drm_device with the right struct device?
>
In [1], mmsys is the drm driver and ovl0 and ovl1 is the sub device
which has dma function.
In this drm, there are two crtc and each one is comprised of many
component.
This is an example of mt8173:
crtc0: ovl0, color0, aal, od, rdma0, ufoe, dsi0
crtc1: ovl1, color1, gamma, rdma1, dpi0
In the device node of ovl0 and ovl1, there is a 'iommus' parameter in
it, so use dma_alloc_xxx() and dma_map_xxx() with that device would get
iova rather than pa. I don't think it's a good idea to register ovl0 or
ovl1 as drm device because each one is just a component in a pipeline.
mmsys controls the clock and routing of multi-media system which include
this drm system, so it's better to register mmsys as drm device. Maybe
we could move 'iommus' parameter from ovl device to mmsys device, so the
dma device changes from ovl device to mmsys device. I'm not sure this
would be a good choice, how do you think?
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/mediatek/mt8173.dtsi?h=v4.19
> - You don't use drm_gem_prime_import_dev, so prime import isn't using the
> right device either.
Yes, you are right. I'm not familiar with whore drm core, so I start to
modify what Mediatek drm use. But this function still works for the drm
device that itself is dma device. If one day there is a drm device which
itself is not a dma device and need this function, send a patch to
modify this function and test it with that drm device. If you want me to
modify all in advance, I'm ok but need others to test it because
Mediatek drm driver does not use them.
>
> - exynos seems to have the same or at least similar issue, stronger case
> for your patches if you can solve both.
I'm still Mediatek's employee. If I modify other company's driver and it
is not a MUST-BE for Mediatek, Mediatek may think I give contribution to
other company. So I've better not to modify exynos driver.
> - I'd start out with using struct drm_gem_cma_object in mtk (similar to
> what vc4 does), and then reusing as much as possible of the existing
> helpers. And then looking later on what's still left (like the support
> for leaving out the virtual mapping).
I'm not clear what vc4 does. It looks like that you want me to redefine
mtk_drm_gem_obj based on drm_gem_cma_object. So it would be like
struct mtk_drm_gem_obj {
struct drm_gem_cma_object base;
void *cookie;
unsigned long dma_attrs;
};
I could try to modify as this and see what have left.
Regards,
CK
>
> -Daniel
>
[Snip...]
> > ---
> > --
> > 1.9.1
> >
>
[PATCH RESEND] spi: spi-fsl-dspi: use IRQF_SHARED mode to request IRQ
Some SoC share one irq number between DSPI controllers.
For example, on the LX2160 board, DSPI0 and DSPI1 share one irq number.
In this case, only one DSPI controller can register successfully,
and others will fail.
Signed-off-by: Chuanhua Han
---
drivers/spi/spi-fsl-dspi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 3082e72e4f6c..5e10dc5c93a5 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -1090,8 +1090,8 @@ static int dspi_probe(struct platform_device *pdev)
goto out_clk_put;
}
- ret = devm_request_irq(>dev, dspi->irq, dspi_interrupt, 0,
- pdev->name, dspi);
+ ret = devm_request_irq(>dev, dspi->irq, dspi_interrupt,
+ IRQF_SHARED, pdev->name, dspi);
if (ret < 0) {
dev_err(>dev, "Unable to attach DSPI interrupt\n");
goto out_clk_put;
--
2.17.1
Re: [PATCH 3/3] drm/mediatek: Use drm_gem_cma_object instead of mtk_drm_gem_obj
Hi,Daniel:
On Fri, 2018-10-26 at 12:21 +0200, Daniel Vetter wrote:
> On Fri, Oct 26, 2018 at 03:22:03PM +0800, CK Hu wrote:
> > After adding dma_dev in struct drm_device and
> > drm_gem_cma_dumb_create_no_kmap(), drm_gem_cma_object could replace
> > mtk_drm_gem_obj, so use drm_gem_cma_object instead of mtk_drm_gem_obj to
> > reduce redundant code.
> >
> > Signed-off-by: CK Hu
>
> A few questions/thoughts:
>
> - Why do you need both drm_device->dev and drm_device->dma_dev? Can't you
> just register the drm_device with the right struct device?
>
In [1], mmsys is the drm driver and ovl0 and ovl1 is the sub device
which has dma function.
In this drm, there are two crtc and each one is comprised of many
component.
This is an example of mt8173:
crtc0: ovl0, color0, aal, od, rdma0, ufoe, dsi0
crtc1: ovl1, color1, gamma, rdma1, dpi0
In the device node of ovl0 and ovl1, there is a 'iommus' parameter in
it, so use dma_alloc_xxx() and dma_map_xxx() with that device would get
iova rather than pa. I don't think it's a good idea to register ovl0 or
ovl1 as drm device because each one is just a component in a pipeline.
mmsys controls the clock and routing of multi-media system which include
this drm system, so it's better to register mmsys as drm device. Maybe
we could move 'iommus' parameter from ovl device to mmsys device, so the
dma device changes from ovl device to mmsys device. I'm not sure this
would be a good choice, how do you think?
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/mediatek/mt8173.dtsi?h=v4.19
> - You don't use drm_gem_prime_import_dev, so prime import isn't using the
> right device either.
Yes, you are right. I'm not familiar with whore drm core, so I start to
modify what Mediatek drm use. But this function still works for the drm
device that itself is dma device. If one day there is a drm device which
itself is not a dma device and need this function, send a patch to
modify this function and test it with that drm device. If you want me to
modify all in advance, I'm ok but need others to test it because
Mediatek drm driver does not use them.
>
> - exynos seems to have the same or at least similar issue, stronger case
> for your patches if you can solve both.
I'm still Mediatek's employee. If I modify other company's driver and it
is not a MUST-BE for Mediatek, Mediatek may think I give contribution to
other company. So I've better not to modify exynos driver.
> - I'd start out with using struct drm_gem_cma_object in mtk (similar to
> what vc4 does), and then reusing as much as possible of the existing
> helpers. And then looking later on what's still left (like the support
> for leaving out the virtual mapping).
I'm not clear what vc4 does. It looks like that you want me to redefine
mtk_drm_gem_obj based on drm_gem_cma_object. So it would be like
struct mtk_drm_gem_obj {
struct drm_gem_cma_object base;
void *cookie;
unsigned long dma_attrs;
};
I could try to modify as this and see what have left.
Regards,
CK
>
> -Daniel
>
[Snip...]
> > ---
> > --
> > 1.9.1
> >
>
[v2, PATCH 0/2] add Ethernet driver support for mt2712
The mt2712 Ethernet IP is from Synopsys, so extend stmmac to support mt2712.
[v2, PATCH 0/2] add Ethernet driver support for mt2712
The mt2712 Ethernet IP is from Synopsys, so extend stmmac to support mt2712.
[PATCH 2/2] dt-binding: mediatek-dwmac: add binding document for MediaTek MT2712 DWMAC
The commit adds the device tree binding documentation for the MediaTek DWMAC
found on MediaTek MT2712.
Signed-off-by: Biao Huang
---
.../devicetree/bindings/net/mediatek-dwmac.txt | 49
1 file changed, 49 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/mediatek-dwmac.txt
diff --git a/Documentation/devicetree/bindings/net/mediatek-dwmac.txt
b/Documentation/devicetree/bindings/net/mediatek-dwmac.txt
new file mode 100644
index 000..8baf0e4
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/mediatek-dwmac.txt
@@ -0,0 +1,49 @@
+MediaTek DWMAC glue layer controller
+
+This file documents platform glue layer for stmmac.
+Please see stmmac.txt for the other unchanged properties.
+
+The device node has following properties.
+
+Required properties:
+- compatible: Should be "mediatek,mt2712-gmac" for MT2712 SoC
+- reg: Address and length of the register set for the device
+- interrupts: Should contain the MAC interrupts
+- interrupt-names: Should contain a list of interrupt names corresponding to
+ the interrupts in the interrupts property, if available.
+ Should be "macirq" for the main MAC IRQ
+- clocks: Must contain a phandle for each entry in clock-names.
+- clock-names: the name of the clock listed in the clocks property. These are
+ "axi", "apb", "mac_ext", "mac_parent", "ptp_ref", "ptp_parent",
"ptp_top"
+ for MT2712 SoC
+- mac-address: See ethernet.txt in the same directory
+- phy-mode: See ethernet.txt in the same directory
+
+Example:
+
+ eth: ethernet@1101c000 {
+ compatible = "mediatek,mt2712-gmac";
+ reg = <0 0x1101c000 0 0x1300>;
+ interrupts = ;
+ interrupt-names = "macirq";
+ phy-mode ="rgmii-id";
+ mac-address = [00 55 7b b5 7d f7];
+ clock-names = "axi",
+ "apb",
+ "mac_ext",
+ "mac_parent",
+ "ptp_ref",
+ "ptp_parent",
+ "ptp_top";
+ clocks = < CLK_PERI_GMAC>,
+< CLK_PERI_GMAC_PCLK>,
+< CLK_TOP_ETHER_125M_SEL>,
+< CLK_TOP_ETHERPLL_125M>,
+< CLK_TOP_ETHER_50M_SEL>,
+< CLK_TOP_APLL1_D3>,
+< CLK_TOP_APLL1>;
+ snps,txpbl = <32>;
+ snps,rxpbl = <32>;
+ snps,reset-gpio = < 87 GPIO_ACTIVE_LOW>;
+ snps,reset-active-low;
+ };
--
1.7.9.5
[PATCH 2/2] dt-binding: mediatek-dwmac: add binding document for MediaTek MT2712 DWMAC
The commit adds the device tree binding documentation for the MediaTek DWMAC
found on MediaTek MT2712.
Signed-off-by: Biao Huang
---
.../devicetree/bindings/net/mediatek-dwmac.txt | 49
1 file changed, 49 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/mediatek-dwmac.txt
diff --git a/Documentation/devicetree/bindings/net/mediatek-dwmac.txt
b/Documentation/devicetree/bindings/net/mediatek-dwmac.txt
new file mode 100644
index 000..8baf0e4
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/mediatek-dwmac.txt
@@ -0,0 +1,49 @@
+MediaTek DWMAC glue layer controller
+
+This file documents platform glue layer for stmmac.
+Please see stmmac.txt for the other unchanged properties.
+
+The device node has following properties.
+
+Required properties:
+- compatible: Should be "mediatek,mt2712-gmac" for MT2712 SoC
+- reg: Address and length of the register set for the device
+- interrupts: Should contain the MAC interrupts
+- interrupt-names: Should contain a list of interrupt names corresponding to
+ the interrupts in the interrupts property, if available.
+ Should be "macirq" for the main MAC IRQ
+- clocks: Must contain a phandle for each entry in clock-names.
+- clock-names: the name of the clock listed in the clocks property. These are
+ "axi", "apb", "mac_ext", "mac_parent", "ptp_ref", "ptp_parent",
"ptp_top"
+ for MT2712 SoC
+- mac-address: See ethernet.txt in the same directory
+- phy-mode: See ethernet.txt in the same directory
+
+Example:
+
+ eth: ethernet@1101c000 {
+ compatible = "mediatek,mt2712-gmac";
+ reg = <0 0x1101c000 0 0x1300>;
+ interrupts = ;
+ interrupt-names = "macirq";
+ phy-mode ="rgmii-id";
+ mac-address = [00 55 7b b5 7d f7];
+ clock-names = "axi",
+ "apb",
+ "mac_ext",
+ "mac_parent",
+ "ptp_ref",
+ "ptp_parent",
+ "ptp_top";
+ clocks = < CLK_PERI_GMAC>,
+< CLK_PERI_GMAC_PCLK>,
+< CLK_TOP_ETHER_125M_SEL>,
+< CLK_TOP_ETHERPLL_125M>,
+< CLK_TOP_ETHER_50M_SEL>,
+< CLK_TOP_APLL1_D3>,
+< CLK_TOP_APLL1>;
+ snps,txpbl = <32>;
+ snps,rxpbl = <32>;
+ snps,reset-gpio = < 87 GPIO_ACTIVE_LOW>;
+ snps,reset-active-low;
+ };
--
1.7.9.5
[PATCH 1/2] net:stmmac: dwmac-mediatek: add support for mt2712
Add Ethernet support for MediaTek SoCs from the mt2712 family
Signed-off-by: Biao Huang
---
drivers/net/ethernet/stmicro/stmmac/Kconfig|8 +
drivers/net/ethernet/stmicro/stmmac/Makefile |1 +
.../net/ethernet/stmicro/stmmac/dwmac-mediatek.c | 364
3 files changed, 373 insertions(+)
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig
b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index edf2036..76d779e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -75,6 +75,14 @@ config DWMAC_LPC18XX
---help---
Support for NXP LPC18xx/43xx DWMAC Ethernet.
+config DWMAC_MEDIATEK
+ tristate "MediaTek MT27xx GMAC support"
+ depends on OF
+ help
+ Support for MediaTek GMAC Ethernet controller.
+
+ This selects the MT2712 SoC support for the stmmac driver.
+
config DWMAC_MESON
tristate "Amlogic Meson dwmac support"
default ARCH_MESON
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile
b/drivers/net/ethernet/stmicro/stmmac/Makefile
index 99967a8..bf09701 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_STMMAC_PLATFORM) += stmmac-platform.o
obj-$(CONFIG_DWMAC_ANARION)+= dwmac-anarion.o
obj-$(CONFIG_DWMAC_IPQ806X)+= dwmac-ipq806x.o
obj-$(CONFIG_DWMAC_LPC18XX)+= dwmac-lpc18xx.o
+obj-$(CONFIG_DWMAC_MEDIATEK) += dwmac-mediatek.o
obj-$(CONFIG_DWMAC_MESON) += dwmac-meson.o dwmac-meson8b.o
obj-$(CONFIG_DWMAC_OXNAS) += dwmac-oxnas.o
obj-$(CONFIG_DWMAC_ROCKCHIP) += dwmac-rk.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c
new file mode 100644
index 000..9ccf3a5
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c
@@ -0,0 +1,364 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (c) 2018 MediaTek Inc.
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "stmmac.h"
+#include "stmmac_platform.h"
+
+/* Peri Configuration register */
+#define PERI_ETH_PHY_INTF_SEL 0x418
+#define PHY_INTF_MII_GMII 0
+#define PHY_INTF_RGMII 1
+#define PHY_INTF_RMII 4
+#define RMII_CLK_SRC_RXC BIT(4)
+#define RMII_CLK_SRC_INTERNAL BIT(5)
+
+#define PERI_ETH_PHY_DLY 0x428
+#define PHY_DLY_GTXC_INV BIT(6)
+#define PHY_DLY_GTXC_ENABLEBIT(5)
+#define PHY_DLY_GTXC_STAGESGENMASK(4, 0)
+#define PHY_DLY_TXC_INVBIT(20)
+#define PHY_DLY_TXC_ENABLE BIT(19)
+#define PHY_DLY_TXC_STAGES GENMASK(18, 14)
+#define PHY_DLY_TXC_SHIFT 14
+#define PHY_DLY_RXC_INVBIT(13)
+#define PHY_DLY_RXC_ENABLE BIT(12)
+#define PHY_DLY_RXC_STAGES GENMASK(11, 7)
+#define PHY_DLY_RXC_SHIFT 7
+
+#define PERI_ETH_DLY_FINE 0x800
+#define ETH_RMII_DLY_TX_INVBIT(2)
+#define ETH_FINE_DLY_GTXC BIT(1)
+#define ETH_FINE_DLY_RXC BIT(0)
+
+enum dwmac_clks_map {
+ DWMAC_CLK_AXI_DRAM,
+ DWMAC_CLK_APB_REG,
+ DWMAC_CLK_MAC_EXT,
+ DWMAC_CLK_MAC_PARENT,
+ DWMAC_CLK_PTP_REF,
+ DWMAC_CLK_PTP_PARENT,
+ DWMAC_CLK_PTP_TOP,
+ DWMAC_CLK_MAX
+};
+
+struct mac_delay_struct {
+ u32 tx_delay;
+ u32 rx_delay;
+ u32 tx_inv;
+ u32 rx_inv;
+};
+
+struct mediatek_dwmac_plat_data {
+ struct device *dev;
+ struct regmap *peri_regmap;
+ struct clk *clks[DWMAC_CLK_MAX];
+ struct device_node *np;
+ int phy_mode;
+ struct mac_delay_struct mac_delay;
+ const struct mediatek_dwmac_variant *variant;
+ int fine_tune;
+ int rmii_rxc;
+};
+
+struct mediatek_dwmac_variant {
+ int (*dwmac_config_dt)(struct mediatek_dwmac_plat_data *plat);
+ int (*dwmac_enable_clks)(struct mediatek_dwmac_plat_data *plat);
+ void (*dwmac_disable_clks)(struct mediatek_dwmac_plat_data *plat);
+};
+
+static const char * const mediatek_dwmac_clks_name[] = {
+ "axi", "apb", "mac_ext", "mac_parent", "ptp_ref", "ptp_parent",
"ptp_top"
+};
+
+static int mt2712_set_interface(struct mediatek_dwmac_plat_data *plat)
+{
+ int rmii_rxc = plat->rmii_rxc ? RMII_CLK_SRC_RXC : 0;
+ u32 intf_val = 0;
+
+ /* select phy interface in top control domain */
+ switch (plat->phy_mode) {
+ case PHY_INTERFACE_MODE_MII:
+ intf_val |= PHY_INTF_MII_GMII;
+ break;
+ case PHY_INTERFACE_MODE_RMII:
+ intf_val |= PHY_INTF_RMII;
+ intf_val |= rmii_rxc;
+ break;
+ case PHY_INTERFACE_MODE_RGMII:
+ case PHY_INTERFACE_MODE_RGMII_TXID:
+ case PHY_INTERFACE_MODE_RGMII_RXID:
+ case PHY_INTERFACE_MODE_RGMII_ID:
+ intf_val |= PHY_INTF_RGMII;
+ break;
+
[PATCH 1/2] net:stmmac: dwmac-mediatek: add support for mt2712
Add Ethernet support for MediaTek SoCs from the mt2712 family
Signed-off-by: Biao Huang
---
drivers/net/ethernet/stmicro/stmmac/Kconfig|8 +
drivers/net/ethernet/stmicro/stmmac/Makefile |1 +
.../net/ethernet/stmicro/stmmac/dwmac-mediatek.c | 364
3 files changed, 373 insertions(+)
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig
b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index edf2036..76d779e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -75,6 +75,14 @@ config DWMAC_LPC18XX
---help---
Support for NXP LPC18xx/43xx DWMAC Ethernet.
+config DWMAC_MEDIATEK
+ tristate "MediaTek MT27xx GMAC support"
+ depends on OF
+ help
+ Support for MediaTek GMAC Ethernet controller.
+
+ This selects the MT2712 SoC support for the stmmac driver.
+
config DWMAC_MESON
tristate "Amlogic Meson dwmac support"
default ARCH_MESON
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile
b/drivers/net/ethernet/stmicro/stmmac/Makefile
index 99967a8..bf09701 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_STMMAC_PLATFORM) += stmmac-platform.o
obj-$(CONFIG_DWMAC_ANARION)+= dwmac-anarion.o
obj-$(CONFIG_DWMAC_IPQ806X)+= dwmac-ipq806x.o
obj-$(CONFIG_DWMAC_LPC18XX)+= dwmac-lpc18xx.o
+obj-$(CONFIG_DWMAC_MEDIATEK) += dwmac-mediatek.o
obj-$(CONFIG_DWMAC_MESON) += dwmac-meson.o dwmac-meson8b.o
obj-$(CONFIG_DWMAC_OXNAS) += dwmac-oxnas.o
obj-$(CONFIG_DWMAC_ROCKCHIP) += dwmac-rk.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c
new file mode 100644
index 000..9ccf3a5
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c
@@ -0,0 +1,364 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (c) 2018 MediaTek Inc.
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "stmmac.h"
+#include "stmmac_platform.h"
+
+/* Peri Configuration register */
+#define PERI_ETH_PHY_INTF_SEL 0x418
+#define PHY_INTF_MII_GMII 0
+#define PHY_INTF_RGMII 1
+#define PHY_INTF_RMII 4
+#define RMII_CLK_SRC_RXC BIT(4)
+#define RMII_CLK_SRC_INTERNAL BIT(5)
+
+#define PERI_ETH_PHY_DLY 0x428
+#define PHY_DLY_GTXC_INV BIT(6)
+#define PHY_DLY_GTXC_ENABLEBIT(5)
+#define PHY_DLY_GTXC_STAGESGENMASK(4, 0)
+#define PHY_DLY_TXC_INVBIT(20)
+#define PHY_DLY_TXC_ENABLE BIT(19)
+#define PHY_DLY_TXC_STAGES GENMASK(18, 14)
+#define PHY_DLY_TXC_SHIFT 14
+#define PHY_DLY_RXC_INVBIT(13)
+#define PHY_DLY_RXC_ENABLE BIT(12)
+#define PHY_DLY_RXC_STAGES GENMASK(11, 7)
+#define PHY_DLY_RXC_SHIFT 7
+
+#define PERI_ETH_DLY_FINE 0x800
+#define ETH_RMII_DLY_TX_INVBIT(2)
+#define ETH_FINE_DLY_GTXC BIT(1)
+#define ETH_FINE_DLY_RXC BIT(0)
+
+enum dwmac_clks_map {
+ DWMAC_CLK_AXI_DRAM,
+ DWMAC_CLK_APB_REG,
+ DWMAC_CLK_MAC_EXT,
+ DWMAC_CLK_MAC_PARENT,
+ DWMAC_CLK_PTP_REF,
+ DWMAC_CLK_PTP_PARENT,
+ DWMAC_CLK_PTP_TOP,
+ DWMAC_CLK_MAX
+};
+
+struct mac_delay_struct {
+ u32 tx_delay;
+ u32 rx_delay;
+ u32 tx_inv;
+ u32 rx_inv;
+};
+
+struct mediatek_dwmac_plat_data {
+ struct device *dev;
+ struct regmap *peri_regmap;
+ struct clk *clks[DWMAC_CLK_MAX];
+ struct device_node *np;
+ int phy_mode;
+ struct mac_delay_struct mac_delay;
+ const struct mediatek_dwmac_variant *variant;
+ int fine_tune;
+ int rmii_rxc;
+};
+
+struct mediatek_dwmac_variant {
+ int (*dwmac_config_dt)(struct mediatek_dwmac_plat_data *plat);
+ int (*dwmac_enable_clks)(struct mediatek_dwmac_plat_data *plat);
+ void (*dwmac_disable_clks)(struct mediatek_dwmac_plat_data *plat);
+};
+
+static const char * const mediatek_dwmac_clks_name[] = {
+ "axi", "apb", "mac_ext", "mac_parent", "ptp_ref", "ptp_parent",
"ptp_top"
+};
+
+static int mt2712_set_interface(struct mediatek_dwmac_plat_data *plat)
+{
+ int rmii_rxc = plat->rmii_rxc ? RMII_CLK_SRC_RXC : 0;
+ u32 intf_val = 0;
+
+ /* select phy interface in top control domain */
+ switch (plat->phy_mode) {
+ case PHY_INTERFACE_MODE_MII:
+ intf_val |= PHY_INTF_MII_GMII;
+ break;
+ case PHY_INTERFACE_MODE_RMII:
+ intf_val |= PHY_INTF_RMII;
+ intf_val |= rmii_rxc;
+ break;
+ case PHY_INTERFACE_MODE_RGMII:
+ case PHY_INTERFACE_MODE_RGMII_TXID:
+ case PHY_INTERFACE_MODE_RGMII_RXID:
+ case PHY_INTERFACE_MODE_RGMII_ID:
+ intf_val |= PHY_INTF_RGMII;
+ break;
+
[PATCH v2 05/12] w1: use octal numbers instead of macros for file mode
This satifies a warning raised by the checkpatch tool.
Signed-off-by: Steffen Vogel
---
drivers/w1/w1.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
index 184df1fe216b..a8ead2350521 100644
--- a/drivers/w1/w1.c
+++ b/drivers/w1/w1.c
@@ -563,18 +563,18 @@ static ssize_t w1_master_attribute_store_remove(struct
device *dev,
w1_master_attribute_show_##_name,\
w1_master_attribute_store_##_name)
-static W1_MASTER_ATTR_RO(name, S_IRUGO);
-static W1_MASTER_ATTR_RO(slaves, S_IRUGO);
-static W1_MASTER_ATTR_RO(slave_count, S_IRUGO);
-static W1_MASTER_ATTR_RW(max_slave_count, S_IRUGO | S_IWUSR | S_IWGRP);
-static W1_MASTER_ATTR_RO(attempts, S_IRUGO);
-static W1_MASTER_ATTR_RO(timeout, S_IRUGO);
-static W1_MASTER_ATTR_RO(timeout_us, S_IRUGO);
-static W1_MASTER_ATTR_RO(pointer, S_IRUGO);
-static W1_MASTER_ATTR_RW(search, S_IRUGO | S_IWUSR | S_IWGRP);
-static W1_MASTER_ATTR_RW(pullup, S_IRUGO | S_IWUSR | S_IWGRP);
-static W1_MASTER_ATTR_RW(add, S_IRUGO | S_IWUSR | S_IWGRP);
-static W1_MASTER_ATTR_RW(remove, S_IRUGO | S_IWUSR | S_IWGRP);
+static W1_MASTER_ATTR_RO(name, 0444);
+static W1_MASTER_ATTR_RO(slaves, 0444);
+static W1_MASTER_ATTR_RO(slave_count, 0444);
+static W1_MASTER_ATTR_RW(max_slave_count, 0664);
+static W1_MASTER_ATTR_RO(attempts, 0444);
+static W1_MASTER_ATTR_RO(timeout, 0444);
+static W1_MASTER_ATTR_RO(timeout_us, 0444);
+static W1_MASTER_ATTR_RO(pointer, 0444);
+static W1_MASTER_ATTR_RW(search, 0664);
+static W1_MASTER_ATTR_RW(pullup, 0664);
+static W1_MASTER_ATTR_RW(add, 0664);
+static W1_MASTER_ATTR_RW(remove, 0664);
static struct attribute *w1_master_default_attrs[] = {
_master_attribute_name.attr,
--
2.11.0
[PATCH v2 09/12] w1: using linux instead of asm prefix for includes
This fixes a warning raised by the checkpatch tool Signed-off-by: Steffen Vogel --- drivers/w1/w1_io.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/w1/w1_io.c b/drivers/w1/w1_io.c index 688778cccf65..65384b332a5a 100644 --- a/drivers/w1/w1_io.c +++ b/drivers/w1/w1_io.c @@ -3,7 +3,7 @@ * Copyright (c) 2004 Evgeniy Polyakov */ -#include +#include #include #include -- 2.11.0
[PATCH v2 02/12] w1: improve code-style by adhering tp 80 columns per line limit
Furthermore indentation of broken lines has been fixed.
This fixes several warnings raised by the checkpatch.pl script.
Signed-off-by: Steffen Vogel
---
drivers/w1/w1.c | 160 +++-
drivers/w1/w1_family.c | 2 +-
drivers/w1/w1_int.c | 15 ++---
drivers/w1/w1_io.c | 33 ++
drivers/w1/w1_netlink.c | 42 -
5 files changed, 145 insertions(+), 107 deletions(-)
diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
index 2c64655b603c..6b3cdc5a09fb 100644
--- a/drivers/w1/w1.c
+++ b/drivers/w1/w1.c
@@ -45,13 +45,11 @@ MODULE_PARM_DESC(timeout_us,
*/
int w1_max_slave_count = 64;
module_param_named(max_slave_count, w1_max_slave_count, int, 0);
-MODULE_PARM_DESC(max_slave_count,
- "maximum number of slaves detected in a search");
+MODULE_PARM_DESC(max_slave_count, "maximum number of slaves detected in a
search");
int w1_max_slave_ttl = 10;
module_param_named(slave_ttl, w1_max_slave_ttl, int, 0);
-MODULE_PARM_DESC(slave_ttl,
- "Number of searches not seeing a slave before it will be removed");
+MODULE_PARM_DESC(slave_ttl, "Number of searches not seeing a slave before it
will be removed");
DEFINE_MUTEX(w1_mlock);
LIST_HEAD(w1_masters);
@@ -85,7 +83,8 @@ static void w1_slave_release(struct device *dev)
sl->master->slave_count--;
}
-static ssize_t name_show(struct device *dev, struct device_attribute *attr,
char *buf)
+static ssize_t name_show(struct device *dev,
+struct device_attribute *attr, char *buf)
{
struct w1_slave *sl = dev_to_w1_slave(dev);
@@ -94,7 +93,7 @@ static ssize_t name_show(struct device *dev, struct
device_attribute *attr, char
static DEVICE_ATTR_RO(name);
static ssize_t id_show(struct device *dev,
- struct device_attribute *attr, char *buf)
+ struct device_attribute *attr, char *buf)
{
struct w1_slave *sl = dev_to_w1_slave(dev);
ssize_t count = sizeof(sl->reg_num);
@@ -203,9 +202,10 @@ struct device w1_slave_device = {
.driver = _slave_driver,
.release = _slave_release
};
-#endif /* 0 */
+#endif
-static ssize_t w1_master_attribute_show_name(struct device *dev, struct
device_attribute *attr, char *buf)
+static ssize_t w1_master_attribute_show_name(struct device *dev,
+struct device_attribute *attr,
char *buf)
{
struct w1_master *md = dev_to_w1_master(dev);
ssize_t count;
@@ -217,9 +217,9 @@ static ssize_t w1_master_attribute_show_name(struct device
*dev, struct device_a
return count;
}
-static ssize_t w1_master_attribute_store_search(struct device * dev,
+static ssize_t w1_master_attribute_store_search(struct device *dev,
struct device_attribute *attr,
- const char * buf, size_t count)
+ const char *buf, size_t count)
{
long tmp;
struct w1_master *md = dev_to_w1_master(dev);
@@ -286,7 +286,9 @@ static ssize_t w1_master_attribute_show_pullup(struct
device *dev,
return count;
}
-static ssize_t w1_master_attribute_show_pointer(struct device *dev, struct
device_attribute *attr, char *buf)
+static ssize_t w1_master_attribute_show_pointer(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
{
struct w1_master *md = dev_to_w1_master(dev);
ssize_t count;
@@ -297,7 +299,9 @@ static ssize_t w1_master_attribute_show_pointer(struct
device *dev, struct devic
return count;
}
-static ssize_t w1_master_attribute_show_timeout(struct device *dev, struct
device_attribute *attr, char *buf)
+static ssize_t w1_master_attribute_show_timeout(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
{
ssize_t count;
count = sprintf(buf, "%d\n", w1_timeout);
@@ -305,7 +309,8 @@ static ssize_t w1_master_attribute_show_timeout(struct
device *dev, struct devic
}
static ssize_t w1_master_attribute_show_timeout_us(struct device *dev,
- struct device_attribute *attr, char *buf)
+ struct device_attribute
*attr,
+ char *buf)
{
ssize_t count;
count = sprintf(buf, "%d\n", w1_timeout_us);
@@ -313,7 +318,9 @@ static ssize_t w1_master_attribute_show_timeout_us(struct
device *dev,
}
static ssize_t w1_master_attribute_store_max_slave_count(struct device *dev,
- struct device_attribute *attr, const char *buf, size_t count)
+struct
device_attribute *attr,
+const char *buf,
+
[PATCH v2 06/12] w1: do not log errors about failed memory allocations
This fixes a warning raised by the checkpatch tool.
Signed-off-by: Steffen Vogel
---
drivers/w1/w1.c | 7 +--
drivers/w1/w1_int.c | 6 +-
2 files changed, 2 insertions(+), 11 deletions(-)
diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
index a8ead2350521..cbfc3f7012de 100644
--- a/drivers/w1/w1.c
+++ b/drivers/w1/w1.c
@@ -757,13 +757,8 @@ int w1_attach_slave_device(struct w1_master *dev, struct
w1_reg_num *rn)
struct w1_netlink_msg msg;
sl = kzalloc(sizeof(struct w1_slave), GFP_KERNEL);
- if (!sl) {
- dev_err(>dev,
-"%s: failed to allocate new slave device.\n",
-__func__);
+ if (!sl)
return -ENOMEM;
- }
-
sl->owner = THIS_MODULE;
sl->master = dev;
diff --git a/drivers/w1/w1_int.c b/drivers/w1/w1_int.c
index efe03b9e23f5..a6c011e57c90 100644
--- a/drivers/w1/w1_int.c
+++ b/drivers/w1/w1_int.c
@@ -33,12 +33,8 @@ static struct w1_master *w1_alloc_dev(u32 id, int
slave_count, int slave_ttl,
*/
dev = kzalloc(sizeof(struct w1_master) +
sizeof(struct w1_bus_master), GFP_KERNEL);
- if (!dev) {
- pr_err("Failed to allocate %zd bytes for new w1 device.\n",
- sizeof(struct w1_master));
+ if (!dev)
return NULL;
- }
-
dev->bus_master = (struct w1_bus_master *)(dev + 1);
--
2.11.0
[PATCH v2 05/12] w1: use octal numbers instead of macros for file mode
This satifies a warning raised by the checkpatch tool.
Signed-off-by: Steffen Vogel
---
drivers/w1/w1.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
index 184df1fe216b..a8ead2350521 100644
--- a/drivers/w1/w1.c
+++ b/drivers/w1/w1.c
@@ -563,18 +563,18 @@ static ssize_t w1_master_attribute_store_remove(struct
device *dev,
w1_master_attribute_show_##_name,\
w1_master_attribute_store_##_name)
-static W1_MASTER_ATTR_RO(name, S_IRUGO);
-static W1_MASTER_ATTR_RO(slaves, S_IRUGO);
-static W1_MASTER_ATTR_RO(slave_count, S_IRUGO);
-static W1_MASTER_ATTR_RW(max_slave_count, S_IRUGO | S_IWUSR | S_IWGRP);
-static W1_MASTER_ATTR_RO(attempts, S_IRUGO);
-static W1_MASTER_ATTR_RO(timeout, S_IRUGO);
-static W1_MASTER_ATTR_RO(timeout_us, S_IRUGO);
-static W1_MASTER_ATTR_RO(pointer, S_IRUGO);
-static W1_MASTER_ATTR_RW(search, S_IRUGO | S_IWUSR | S_IWGRP);
-static W1_MASTER_ATTR_RW(pullup, S_IRUGO | S_IWUSR | S_IWGRP);
-static W1_MASTER_ATTR_RW(add, S_IRUGO | S_IWUSR | S_IWGRP);
-static W1_MASTER_ATTR_RW(remove, S_IRUGO | S_IWUSR | S_IWGRP);
+static W1_MASTER_ATTR_RO(name, 0444);
+static W1_MASTER_ATTR_RO(slaves, 0444);
+static W1_MASTER_ATTR_RO(slave_count, 0444);
+static W1_MASTER_ATTR_RW(max_slave_count, 0664);
+static W1_MASTER_ATTR_RO(attempts, 0444);
+static W1_MASTER_ATTR_RO(timeout, 0444);
+static W1_MASTER_ATTR_RO(timeout_us, 0444);
+static W1_MASTER_ATTR_RO(pointer, 0444);
+static W1_MASTER_ATTR_RW(search, 0664);
+static W1_MASTER_ATTR_RW(pullup, 0664);
+static W1_MASTER_ATTR_RW(add, 0664);
+static W1_MASTER_ATTR_RW(remove, 0664);
static struct attribute *w1_master_default_attrs[] = {
_master_attribute_name.attr,
--
2.11.0
[PATCH v2 09/12] w1: using linux instead of asm prefix for includes
This fixes a warning raised by the checkpatch tool Signed-off-by: Steffen Vogel --- drivers/w1/w1_io.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/w1/w1_io.c b/drivers/w1/w1_io.c index 688778cccf65..65384b332a5a 100644 --- a/drivers/w1/w1_io.c +++ b/drivers/w1/w1_io.c @@ -3,7 +3,7 @@ * Copyright (c) 2004 Evgeniy Polyakov */ -#include +#include #include #include -- 2.11.0
[PATCH v2 02/12] w1: improve code-style by adhering tp 80 columns per line limit
Furthermore indentation of broken lines has been fixed.
This fixes several warnings raised by the checkpatch.pl script.
Signed-off-by: Steffen Vogel
---
drivers/w1/w1.c | 160 +++-
drivers/w1/w1_family.c | 2 +-
drivers/w1/w1_int.c | 15 ++---
drivers/w1/w1_io.c | 33 ++
drivers/w1/w1_netlink.c | 42 -
5 files changed, 145 insertions(+), 107 deletions(-)
diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
index 2c64655b603c..6b3cdc5a09fb 100644
--- a/drivers/w1/w1.c
+++ b/drivers/w1/w1.c
@@ -45,13 +45,11 @@ MODULE_PARM_DESC(timeout_us,
*/
int w1_max_slave_count = 64;
module_param_named(max_slave_count, w1_max_slave_count, int, 0);
-MODULE_PARM_DESC(max_slave_count,
- "maximum number of slaves detected in a search");
+MODULE_PARM_DESC(max_slave_count, "maximum number of slaves detected in a
search");
int w1_max_slave_ttl = 10;
module_param_named(slave_ttl, w1_max_slave_ttl, int, 0);
-MODULE_PARM_DESC(slave_ttl,
- "Number of searches not seeing a slave before it will be removed");
+MODULE_PARM_DESC(slave_ttl, "Number of searches not seeing a slave before it
will be removed");
DEFINE_MUTEX(w1_mlock);
LIST_HEAD(w1_masters);
@@ -85,7 +83,8 @@ static void w1_slave_release(struct device *dev)
sl->master->slave_count--;
}
-static ssize_t name_show(struct device *dev, struct device_attribute *attr,
char *buf)
+static ssize_t name_show(struct device *dev,
+struct device_attribute *attr, char *buf)
{
struct w1_slave *sl = dev_to_w1_slave(dev);
@@ -94,7 +93,7 @@ static ssize_t name_show(struct device *dev, struct
device_attribute *attr, char
static DEVICE_ATTR_RO(name);
static ssize_t id_show(struct device *dev,
- struct device_attribute *attr, char *buf)
+ struct device_attribute *attr, char *buf)
{
struct w1_slave *sl = dev_to_w1_slave(dev);
ssize_t count = sizeof(sl->reg_num);
@@ -203,9 +202,10 @@ struct device w1_slave_device = {
.driver = _slave_driver,
.release = _slave_release
};
-#endif /* 0 */
+#endif
-static ssize_t w1_master_attribute_show_name(struct device *dev, struct
device_attribute *attr, char *buf)
+static ssize_t w1_master_attribute_show_name(struct device *dev,
+struct device_attribute *attr,
char *buf)
{
struct w1_master *md = dev_to_w1_master(dev);
ssize_t count;
@@ -217,9 +217,9 @@ static ssize_t w1_master_attribute_show_name(struct device
*dev, struct device_a
return count;
}
-static ssize_t w1_master_attribute_store_search(struct device * dev,
+static ssize_t w1_master_attribute_store_search(struct device *dev,
struct device_attribute *attr,
- const char * buf, size_t count)
+ const char *buf, size_t count)
{
long tmp;
struct w1_master *md = dev_to_w1_master(dev);
@@ -286,7 +286,9 @@ static ssize_t w1_master_attribute_show_pullup(struct
device *dev,
return count;
}
-static ssize_t w1_master_attribute_show_pointer(struct device *dev, struct
device_attribute *attr, char *buf)
+static ssize_t w1_master_attribute_show_pointer(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
{
struct w1_master *md = dev_to_w1_master(dev);
ssize_t count;
@@ -297,7 +299,9 @@ static ssize_t w1_master_attribute_show_pointer(struct
device *dev, struct devic
return count;
}
-static ssize_t w1_master_attribute_show_timeout(struct device *dev, struct
device_attribute *attr, char *buf)
+static ssize_t w1_master_attribute_show_timeout(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
{
ssize_t count;
count = sprintf(buf, "%d\n", w1_timeout);
@@ -305,7 +309,8 @@ static ssize_t w1_master_attribute_show_timeout(struct
device *dev, struct devic
}
static ssize_t w1_master_attribute_show_timeout_us(struct device *dev,
- struct device_attribute *attr, char *buf)
+ struct device_attribute
*attr,
+ char *buf)
{
ssize_t count;
count = sprintf(buf, "%d\n", w1_timeout_us);
@@ -313,7 +318,9 @@ static ssize_t w1_master_attribute_show_timeout_us(struct
device *dev,
}
static ssize_t w1_master_attribute_store_max_slave_count(struct device *dev,
- struct device_attribute *attr, const char *buf, size_t count)
+struct
device_attribute *attr,
+const char *buf,
+
[PATCH v2 06/12] w1: do not log errors about failed memory allocations
This fixes a warning raised by the checkpatch tool.
Signed-off-by: Steffen Vogel
---
drivers/w1/w1.c | 7 +--
drivers/w1/w1_int.c | 6 +-
2 files changed, 2 insertions(+), 11 deletions(-)
diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
index a8ead2350521..cbfc3f7012de 100644
--- a/drivers/w1/w1.c
+++ b/drivers/w1/w1.c
@@ -757,13 +757,8 @@ int w1_attach_slave_device(struct w1_master *dev, struct
w1_reg_num *rn)
struct w1_netlink_msg msg;
sl = kzalloc(sizeof(struct w1_slave), GFP_KERNEL);
- if (!sl) {
- dev_err(>dev,
-"%s: failed to allocate new slave device.\n",
-__func__);
+ if (!sl)
return -ENOMEM;
- }
-
sl->owner = THIS_MODULE;
sl->master = dev;
diff --git a/drivers/w1/w1_int.c b/drivers/w1/w1_int.c
index efe03b9e23f5..a6c011e57c90 100644
--- a/drivers/w1/w1_int.c
+++ b/drivers/w1/w1_int.c
@@ -33,12 +33,8 @@ static struct w1_master *w1_alloc_dev(u32 id, int
slave_count, int slave_ttl,
*/
dev = kzalloc(sizeof(struct w1_master) +
sizeof(struct w1_bus_master), GFP_KERNEL);
- if (!dev) {
- pr_err("Failed to allocate %zd bytes for new w1 device.\n",
- sizeof(struct w1_master));
+ if (!dev)
return NULL;
- }
-
dev->bus_master = (struct w1_bus_master *)(dev + 1);
--
2.11.0
[PATCH v2 07/12] w1: use __func__ for logging the function name
This fixes a warning raised by the checkpatch tool.
Signed-off-by: Steffen Vogel
---
drivers/w1/w1.c | 5 +++--
drivers/w1/w1_int.c | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
index cbfc3f7012de..4cbe1849fbfc 100644
--- a/drivers/w1/w1.c
+++ b/drivers/w1/w1.c
@@ -1066,7 +1066,8 @@ void w1_search(struct w1_master *dev, u8 search_type,
if (test_bit(W1_ABORT_SEARCH, >flags)) {
mutex_unlock(>bus_mutex);
- dev_dbg(>dev, "Abort w1_search\n");
+ dev_dbg(>dev, "Abort %s\n", __func__);
+
return;
}
}
@@ -1094,7 +1095,7 @@ void w1_search(struct w1_master *dev, u8 search_type,
* bus).
*/
dev_info(>dev, "%s: max_slave_count %d reached,
will continue next search.\n",
- __func__, dev->max_slave_count);
+__func__, dev->max_slave_count);
set_bit(W1_WARN_MAX_COUNT, >flags);
}
}
diff --git a/drivers/w1/w1_int.c b/drivers/w1/w1_int.c
index a6c011e57c90..a5230c0d49e3 100644
--- a/drivers/w1/w1_int.c
+++ b/drivers/w1/w1_int.c
@@ -98,7 +98,7 @@ int w1_add_master_device(struct w1_bus_master *master)
if (!(master->touch_bit && master->reset_bus) &&
!(master->write_bit && master->read_bit) &&
!(master->write_byte && master->read_byte && master->reset_bus)) {
- pr_err("w1_add_master_device: invalid function set\n");
+ pr_err("%s: invalid function set\n", __func__);
return(-EINVAL);
}
--
2.11.0
[PATCH v2 11/12] w1: replace non-standard %LX format-string by %llX
As indicated by checkpatch.pl script. Signed-off-by: Steffen Vogel --- drivers/w1/w1.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c index 87094d99ccbe..1326bd52888a 100644 --- a/drivers/w1/w1.c +++ b/drivers/w1/w1.c @@ -636,7 +636,7 @@ static int w1_uevent(struct device *dev, struct kobj_uevent_env *env) if (err) goto end; - err = add_uevent_var(env, "W1_SLAVE_ID=%024LX", + err = add_uevent_var(env, "W1_SLAVE_ID=%024llX", (unsigned long long)sl->reg_num.id); end: return err; -- 2.11.0
[PATCH v2 07/12] w1: use __func__ for logging the function name
This fixes a warning raised by the checkpatch tool.
Signed-off-by: Steffen Vogel
---
drivers/w1/w1.c | 5 +++--
drivers/w1/w1_int.c | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
index cbfc3f7012de..4cbe1849fbfc 100644
--- a/drivers/w1/w1.c
+++ b/drivers/w1/w1.c
@@ -1066,7 +1066,8 @@ void w1_search(struct w1_master *dev, u8 search_type,
if (test_bit(W1_ABORT_SEARCH, >flags)) {
mutex_unlock(>bus_mutex);
- dev_dbg(>dev, "Abort w1_search\n");
+ dev_dbg(>dev, "Abort %s\n", __func__);
+
return;
}
}
@@ -1094,7 +1095,7 @@ void w1_search(struct w1_master *dev, u8 search_type,
* bus).
*/
dev_info(>dev, "%s: max_slave_count %d reached,
will continue next search.\n",
- __func__, dev->max_slave_count);
+__func__, dev->max_slave_count);
set_bit(W1_WARN_MAX_COUNT, >flags);
}
}
diff --git a/drivers/w1/w1_int.c b/drivers/w1/w1_int.c
index a6c011e57c90..a5230c0d49e3 100644
--- a/drivers/w1/w1_int.c
+++ b/drivers/w1/w1_int.c
@@ -98,7 +98,7 @@ int w1_add_master_device(struct w1_bus_master *master)
if (!(master->touch_bit && master->reset_bus) &&
!(master->write_bit && master->read_bit) &&
!(master->write_byte && master->read_byte && master->reset_bus)) {
- pr_err("w1_add_master_device: invalid function set\n");
+ pr_err("%s: invalid function set\n", __func__);
return(-EINVAL);
}
--
2.11.0
[PATCH v2 11/12] w1: replace non-standard %LX format-string by %llX
As indicated by checkpatch.pl script. Signed-off-by: Steffen Vogel --- drivers/w1/w1.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c index 87094d99ccbe..1326bd52888a 100644 --- a/drivers/w1/w1.c +++ b/drivers/w1/w1.c @@ -636,7 +636,7 @@ static int w1_uevent(struct device *dev, struct kobj_uevent_env *env) if (err) goto end; - err = add_uevent_var(env, "W1_SLAVE_ID=%024LX", + err = add_uevent_var(env, "W1_SLAVE_ID=%024llX", (unsigned long long)sl->reg_num.id); end: return err; -- 2.11.0
Re: [PATCH V2 1/3] blk-mq: refactor the code of issue request directly
On Sat, Oct 27, 2018 at 12:01:09AM +0800, Jianchao Wang wrote: > Merge blk_mq_try_issue_directly and __blk_mq_try_issue_directly > into one interface which is able to handle the return value from > .queue_rq callback. Due to we can only issue directly w/o io > scheduler, so remove the blk_mq_get_driver_tag. It isn't correct for dm-rq, see blk_insert_cloned_request(). Thanks, Ming
Re: [PATCH V2 1/3] blk-mq: refactor the code of issue request directly
On Sat, Oct 27, 2018 at 12:01:09AM +0800, Jianchao Wang wrote: > Merge blk_mq_try_issue_directly and __blk_mq_try_issue_directly > into one interface which is able to handle the return value from > .queue_rq callback. Due to we can only issue directly w/o io > scheduler, so remove the blk_mq_get_driver_tag. It isn't correct for dm-rq, see blk_insert_cloned_request(). Thanks, Ming
[GIT] Networking
1) GRO overflow entries are not unlinked properly, resulting in list poison pointers being dereferenced. 2) Fix bridge build with ipv6 disabled, from Nikolay Aleksandrov. 3) Direct packet access and other fixes in BPF from Daniel Borkmann. 4) gred_change_table_def() gets passed the wrong pointer, a pointer to a set of unparsed attributes instead of the attribute itself. From Jakub Kicinski. 5) Allow macsec device to be brought up even if it's lowerdev is down, from Sabrina Dubroca. Please pull, thanks a lot! The following changes since commit 345671ea0f9258f410eb057b9ced9cefbbe5dc78: Merge branch 'akpm' (patches from Andrew) (2018-10-26 19:33:41 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git for you to fetch changes up to 747569b0a7c537d680bc94a988be6caad9960488: net: diag: document swapped src/dst in udp_dump_one. (2018-10-28 19:27:21 -0700) Alexei Starovoitov (1): Merge branch 'pkt-access-fixes' Daniel Borkmann (9): bpf: fix test suite to enable all unpriv program types bpf: disallow direct packet access for unpriv in cg_skb bpf: fix direct packet access for flow dissector progs bpf: fix cg_skb types to hint access type in may_access_direct_pkt_data bpf: fix direct packet write into pop/peek helpers bpf: fix leaking uninitialized memory on pop/peek helpers bpf: make direct packet write unclone more robust bpf: add bpf_jit_limit knob to restrict unpriv allocations bpf: fix wrong helper enablement in cgroup local storage David S. Miller (3): Merge git://git.kernel.org/.../bpf/bpf net: Properly unlink GRO packets on overflow. Merge branch 'macsec-fixes' Jakub Kicinski (1): net: sched: gred: pass the right attribute to gred_change_table_def() Lorenzo Colitti (1): net: diag: document swapped src/dst in udp_dump_one. Martin Lau (1): bpf, btf: fix a missing check bug in btf_parse Naresh Kamboju (1): selftests/bpf: add config fragments BPF_STREAM_PARSER and XDP_SOCKETS Nikolay Aleksandrov (1): net: bridge: remove ipv6 zero address check in mcast queries Rasmus Villemoes (1): ptp: drop redundant kasprintf() to create worker name Sabrina Dubroca (2): macsec: update operstate when lower device changes macsec: let the administrator set UP state even if lowerdev is down Taehee Yoo (1): bpf: devmap: fix wrong interface selection in notifier_call Documentation/sysctl/net.txt| 8 drivers/net/macsec.c| 20 +--- drivers/ptp/ptp_clock.c | 6 +- include/linux/filter.h | 1 + kernel/bpf/btf.c| 58 +- kernel/bpf/core.c | 49 ++--- kernel/bpf/devmap.c | 3 +-- kernel/bpf/helpers.c| 2 -- kernel/bpf/queue_stack_maps.c | 2 ++ kernel/bpf/verifier.c | 13 ++--- net/bridge/br_multicast.c | 3 +-- net/core/dev.c | 2 +- net/core/filter.c | 21 + net/core/sysctl_net_core.c | 10 -- net/ipv4/udp_diag.c | 1 + net/sched/sch_gred.c| 2 +- tools/testing/selftests/bpf/config | 2 ++ tools/testing/selftests/bpf/test_verifier.c | 15 +-- 18 files changed, 155 insertions(+), 63 deletions(-)
[GIT] Networking
1) GRO overflow entries are not unlinked properly, resulting in list poison pointers being dereferenced. 2) Fix bridge build with ipv6 disabled, from Nikolay Aleksandrov. 3) Direct packet access and other fixes in BPF from Daniel Borkmann. 4) gred_change_table_def() gets passed the wrong pointer, a pointer to a set of unparsed attributes instead of the attribute itself. From Jakub Kicinski. 5) Allow macsec device to be brought up even if it's lowerdev is down, from Sabrina Dubroca. Please pull, thanks a lot! The following changes since commit 345671ea0f9258f410eb057b9ced9cefbbe5dc78: Merge branch 'akpm' (patches from Andrew) (2018-10-26 19:33:41 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git for you to fetch changes up to 747569b0a7c537d680bc94a988be6caad9960488: net: diag: document swapped src/dst in udp_dump_one. (2018-10-28 19:27:21 -0700) Alexei Starovoitov (1): Merge branch 'pkt-access-fixes' Daniel Borkmann (9): bpf: fix test suite to enable all unpriv program types bpf: disallow direct packet access for unpriv in cg_skb bpf: fix direct packet access for flow dissector progs bpf: fix cg_skb types to hint access type in may_access_direct_pkt_data bpf: fix direct packet write into pop/peek helpers bpf: fix leaking uninitialized memory on pop/peek helpers bpf: make direct packet write unclone more robust bpf: add bpf_jit_limit knob to restrict unpriv allocations bpf: fix wrong helper enablement in cgroup local storage David S. Miller (3): Merge git://git.kernel.org/.../bpf/bpf net: Properly unlink GRO packets on overflow. Merge branch 'macsec-fixes' Jakub Kicinski (1): net: sched: gred: pass the right attribute to gred_change_table_def() Lorenzo Colitti (1): net: diag: document swapped src/dst in udp_dump_one. Martin Lau (1): bpf, btf: fix a missing check bug in btf_parse Naresh Kamboju (1): selftests/bpf: add config fragments BPF_STREAM_PARSER and XDP_SOCKETS Nikolay Aleksandrov (1): net: bridge: remove ipv6 zero address check in mcast queries Rasmus Villemoes (1): ptp: drop redundant kasprintf() to create worker name Sabrina Dubroca (2): macsec: update operstate when lower device changes macsec: let the administrator set UP state even if lowerdev is down Taehee Yoo (1): bpf: devmap: fix wrong interface selection in notifier_call Documentation/sysctl/net.txt| 8 drivers/net/macsec.c| 20 +--- drivers/ptp/ptp_clock.c | 6 +- include/linux/filter.h | 1 + kernel/bpf/btf.c| 58 +- kernel/bpf/core.c | 49 ++--- kernel/bpf/devmap.c | 3 +-- kernel/bpf/helpers.c| 2 -- kernel/bpf/queue_stack_maps.c | 2 ++ kernel/bpf/verifier.c | 13 ++--- net/bridge/br_multicast.c | 3 +-- net/core/dev.c | 2 +- net/core/filter.c | 21 + net/core/sysctl_net_core.c | 10 -- net/ipv4/udp_diag.c | 1 + net/sched/sch_gred.c| 2 +- tools/testing/selftests/bpf/config | 2 ++ tools/testing/selftests/bpf/test_verifier.c | 15 +-- 18 files changed, 155 insertions(+), 63 deletions(-)
Can VFIO pin only a specific region of guest mem when use pass through devices?
Hi, I am using network device pass through mode with qemu x86(-device vfio-pci,host=:xx:yy.z) and “intel_iommu=on” in host kernel command line, and it shows the whole guest memory were pinned(vfio_pin_pages()), viewed by the “top” RES memory output. I understand it is due to device can DMA to any guest memory address and it cannot be swapped. However can we just pin a rang of address space allowed by iommu group of that device, instead of pin whole address space? I do notice some code like vtd_host_dma_iommu(). Maybe there is already some way to enable that? Sorry if I missed some basics. I googled some but no luck to find the answer yet. Please let me know if any discussion already raised on that. Any other suggestion will also be appreciated. For example, can we modify the guest network card driver to allocate only from a specific memory region(zone), and qemu advises guest kernel to only pin that memory region(zone) accordingly? Thanks, - Simon
Can VFIO pin only a specific region of guest mem when use pass through devices?
Hi, I am using network device pass through mode with qemu x86(-device vfio-pci,host=:xx:yy.z) and “intel_iommu=on” in host kernel command line, and it shows the whole guest memory were pinned(vfio_pin_pages()), viewed by the “top” RES memory output. I understand it is due to device can DMA to any guest memory address and it cannot be swapped. However can we just pin a rang of address space allowed by iommu group of that device, instead of pin whole address space? I do notice some code like vtd_host_dma_iommu(). Maybe there is already some way to enable that? Sorry if I missed some basics. I googled some but no luck to find the answer yet. Please let me know if any discussion already raised on that. Any other suggestion will also be appreciated. For example, can we modify the guest network card driver to allocate only from a specific memory region(zone), and qemu advises guest kernel to only pin that memory region(zone) accordingly? Thanks, - Simon
RE: [PATCH 3/6] PCI: layerscape: Add the EP mode support
-Original Message- From: Li Yang Sent: 2018年10月27日 4:29 To: Xiaowei Bao Cc: Arnd Bergmann ; Rob Herring ; Bjorn Helgaas ; Mark Rutland ; Shawn Guo ; kis...@ti.com; lorenzo.pieral...@arm.com; Greg Kroah-Hartman ; M.h. Lian ; Mingkai Hu ; Roy Zang ; Kate Stewart ; cyrille.pitc...@free-electrons.com; Philippe Ombredanne ; shawn@rock-chips.com; niklas.cas...@axis.com; linux-...@vger.kernel.org; open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS ; lkml ; moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE ; linuxppc-dev Subject: Re: [PATCH 3/6] PCI: layerscape: Add the EP mode support On Fri, Oct 26, 2018 at 2:43 AM Xiaowei Bao wrote: > > > > -Original Message- > From: arndbergm...@gmail.com On Behalf Of > Arnd Bergmann > Sent: 2018年10月26日 15:01 > To: Xiaowei Bao > Cc: Rob Herring ; bhelg...@google.com; > mark.rutl...@arm.com; shawn...@kernel.org; Leo Li > ; kis...@ti.com; lorenzo.pieral...@arm.com; > gre...@linuxfoundation.org; M.h. Lian ; Mingkai > Hu ; Roy Zang ; > kstew...@linuxfoundation.org; cyrille.pitc...@free-electrons.com; > pombreda...@nexb.com; shawn@rock-chips.com; > niklas.cas...@axis.com; linux-...@vger.kernel.org; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; > linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org > Subject: Re: [PATCH 3/6] PCI: layerscape: Add the EP mode support > > On 10/26/18, Xiaowei Bao wrote: > > From: Rob Herring > >> On Thu, Oct 25, 2018 at 07:08:58PM +0800, Xiaowei Bao wrote: > >>> "fsl,ls2080a-pcie", "fsl,ls2085a-pcie", "snps,dw-pcie" > >>> "fsl,ls2088a-pcie" > >>> "fsl,ls1088a-pcie" > >>> "fsl,ls1046a-pcie" > >>> "fsl,ls1012a-pcie > >>> + EP mode: > >>> +"fsl,ls-pcie-ep" > >> > > > You need SoC specific compatibles for the same reasons as the RC. > > > > [Xiaowei Bao] I want to contains all layerscape platform use one > > compatible if the PCIe controller work in EP mode. > > Do you mean only one of the SoCs that support RC mode has EP mode? > I think you still need a SoC specific compatible as Rob explained, in case > there will be a second one in the future. > > If you want to ensure that you don't have to update the device driver for > each new chip that comes in when the EP mode is compatible, the way this is > handled is to list multiple values in the compatible property, listing the > first SoC that introduced the specific version of that IP block as the most > generic type, e.g. > > copatible = "fsl,ls2088a-pcie-ep", "fsl,ls1012a-pcie-ep", > "snps,dw-pcie-ep"; > > For consistency, it probably is best to match each RC mode value with the > corresponding EP mode string for each device that can support both (if there > is more than one). > > Arnd > [Xiaowei Bao] My mean is that the ls-pcie-ep compatibles will contain all > layerscape SOCs of NXP, e.g: ls1046a-pcie-ep, fsl,ls2088a-pcie-ep, > ls2088a-pcie-ep and so on, other layerscape SOCs have not test except the > ls1046a, I think it is compatible if the new chip or other SOCs use the DW > core, OK, I will discuss this issue internally, and reply to you later. You can define a generic compatible string for the EP mode of all these platforms. But like Rob and Arnd mentioned, it is good to also define the SoC specific compatible strings just in case that we need special treatment for certain SoCs in the future. Regards, Leo [Xiaowei Bao] Hi Leo, OK, I will add the SoC specific compatible strings in patch-v2, thanks a lot.
RE: [PATCH 3/6] PCI: layerscape: Add the EP mode support
-Original Message- From: Li Yang Sent: 2018年10月27日 4:29 To: Xiaowei Bao Cc: Arnd Bergmann ; Rob Herring ; Bjorn Helgaas ; Mark Rutland ; Shawn Guo ; kis...@ti.com; lorenzo.pieral...@arm.com; Greg Kroah-Hartman ; M.h. Lian ; Mingkai Hu ; Roy Zang ; Kate Stewart ; cyrille.pitc...@free-electrons.com; Philippe Ombredanne ; shawn@rock-chips.com; niklas.cas...@axis.com; linux-...@vger.kernel.org; open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS ; lkml ; moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE ; linuxppc-dev Subject: Re: [PATCH 3/6] PCI: layerscape: Add the EP mode support On Fri, Oct 26, 2018 at 2:43 AM Xiaowei Bao wrote: > > > > -Original Message- > From: arndbergm...@gmail.com On Behalf Of > Arnd Bergmann > Sent: 2018年10月26日 15:01 > To: Xiaowei Bao > Cc: Rob Herring ; bhelg...@google.com; > mark.rutl...@arm.com; shawn...@kernel.org; Leo Li > ; kis...@ti.com; lorenzo.pieral...@arm.com; > gre...@linuxfoundation.org; M.h. Lian ; Mingkai > Hu ; Roy Zang ; > kstew...@linuxfoundation.org; cyrille.pitc...@free-electrons.com; > pombreda...@nexb.com; shawn@rock-chips.com; > niklas.cas...@axis.com; linux-...@vger.kernel.org; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; > linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org > Subject: Re: [PATCH 3/6] PCI: layerscape: Add the EP mode support > > On 10/26/18, Xiaowei Bao wrote: > > From: Rob Herring > >> On Thu, Oct 25, 2018 at 07:08:58PM +0800, Xiaowei Bao wrote: > >>> "fsl,ls2080a-pcie", "fsl,ls2085a-pcie", "snps,dw-pcie" > >>> "fsl,ls2088a-pcie" > >>> "fsl,ls1088a-pcie" > >>> "fsl,ls1046a-pcie" > >>> "fsl,ls1012a-pcie > >>> + EP mode: > >>> +"fsl,ls-pcie-ep" > >> > > > You need SoC specific compatibles for the same reasons as the RC. > > > > [Xiaowei Bao] I want to contains all layerscape platform use one > > compatible if the PCIe controller work in EP mode. > > Do you mean only one of the SoCs that support RC mode has EP mode? > I think you still need a SoC specific compatible as Rob explained, in case > there will be a second one in the future. > > If you want to ensure that you don't have to update the device driver for > each new chip that comes in when the EP mode is compatible, the way this is > handled is to list multiple values in the compatible property, listing the > first SoC that introduced the specific version of that IP block as the most > generic type, e.g. > > copatible = "fsl,ls2088a-pcie-ep", "fsl,ls1012a-pcie-ep", > "snps,dw-pcie-ep"; > > For consistency, it probably is best to match each RC mode value with the > corresponding EP mode string for each device that can support both (if there > is more than one). > > Arnd > [Xiaowei Bao] My mean is that the ls-pcie-ep compatibles will contain all > layerscape SOCs of NXP, e.g: ls1046a-pcie-ep, fsl,ls2088a-pcie-ep, > ls2088a-pcie-ep and so on, other layerscape SOCs have not test except the > ls1046a, I think it is compatible if the new chip or other SOCs use the DW > core, OK, I will discuss this issue internally, and reply to you later. You can define a generic compatible string for the EP mode of all these platforms. But like Rob and Arnd mentioned, it is good to also define the SoC specific compatible strings just in case that we need special treatment for certain SoCs in the future. Regards, Leo [Xiaowei Bao] Hi Leo, OK, I will add the SoC specific compatible strings in patch-v2, thanks a lot.
Re: [PATCHv2] mm/page_owner: use kvmalloc instead of kmalloc
On Mon, Oct 29, 2018 at 10:16:43AM +0800, miles.c...@mediatek.com wrote: > The kbuf used by page owner is allocated by kmalloc(), which means it > can use only normal memory and there might be a "out of memory" > issue when we're out of normal memory. > > Use kvmalloc() so we can also allocate kbuf from > normal/hihghmem on 32bit kernel. That's a misconception: ret = kmalloc_node(size, kmalloc_flags, node); /* * It doesn't really make sense to fallback to vmalloc for sub page * requests */ if (ret || size <= PAGE_SIZE) return ret; Now, maybe this is an opportunity for us to improve kvmalloc. Maybe like this ... diff --git a/mm/util.c b/mm/util.c index 8bf08b5b5760..fdf5b34d2c28 100644 --- a/mm/util.c +++ b/mm/util.c @@ -416,10 +416,10 @@ void *kvmalloc_node(size_t size, gfp_t flags, int node) ret = kmalloc_node(size, kmalloc_flags, node); /* -* It doesn't really make sense to fallback to vmalloc for sub page -* requests +* It only makes sense to fallback to vmalloc for sub page +* requests if we might be able to allocate highmem pages. */ - if (ret || size <= PAGE_SIZE) + if (ret || (!IS_ENABLED(CONFIG_HIGHMEM) && size <= PAGE_SIZE)) return ret; return __vmalloc_node_flags_caller(size, node, flags,
Re: [PATCHv2] mm/page_owner: use kvmalloc instead of kmalloc
On Mon, Oct 29, 2018 at 10:16:43AM +0800, miles.c...@mediatek.com wrote: > The kbuf used by page owner is allocated by kmalloc(), which means it > can use only normal memory and there might be a "out of memory" > issue when we're out of normal memory. > > Use kvmalloc() so we can also allocate kbuf from > normal/hihghmem on 32bit kernel. That's a misconception: ret = kmalloc_node(size, kmalloc_flags, node); /* * It doesn't really make sense to fallback to vmalloc for sub page * requests */ if (ret || size <= PAGE_SIZE) return ret; Now, maybe this is an opportunity for us to improve kvmalloc. Maybe like this ... diff --git a/mm/util.c b/mm/util.c index 8bf08b5b5760..fdf5b34d2c28 100644 --- a/mm/util.c +++ b/mm/util.c @@ -416,10 +416,10 @@ void *kvmalloc_node(size_t size, gfp_t flags, int node) ret = kmalloc_node(size, kmalloc_flags, node); /* -* It doesn't really make sense to fallback to vmalloc for sub page -* requests +* It only makes sense to fallback to vmalloc for sub page +* requests if we might be able to allocate highmem pages. */ - if (ret || size <= PAGE_SIZE) + if (ret || (!IS_ENABLED(CONFIG_HIGHMEM) && size <= PAGE_SIZE)) return ret; return __vmalloc_node_flags_caller(size, node, flags,
RE: [PATCH] binder: ipc namespace support for android binder
>> Hi >> We are working for running android in container, but we found that binder >> is >> not isolated by ipc namespace. Since binder is a form of IPC and therefore >> should >> be tied to ipc namespace. With this patch, we can run more than one android >> container on one host. >> This patch move "binder_procs" and "binder_context" into ipc_namespace, >> driver will find the context from it when opening. Althought statistics in >> debugfs >> remain global. >> >> Signed-off-by: choury zhou >> --- >> drivers/android/Kconfig | 2 +- >> drivers/android/binder.c | 126 +- >> include/linux/ipc_namespace.h | 14 >> ipc/namespace.c | 4 ++ >> 4 files changed, 111 insertions(+), 35 deletions(-) >> >> diff --git a/drivers/android/Kconfig b/drivers/android/Kconfig >> index 432e9ad77070..09883443b2da 100644 >> --- a/drivers/android/Kconfig >> +++ b/drivers/android/Kconfig >> @@ -10,7 +10,7 @@ if ANDROID >> >> config ANDROID_BINDER_IPC >> bool "Android Binder IPC Driver" >> - depends on MMU >> + depends on MMU && SYSVIPC > > NAK. We can't force SYSVIPC on for Android. The notion of running > binder in a container is reasonable, but needs to be done without > explicit requirement for SYSVIPC. binder-in-container is a topic in > the android microconf at Linux plumbers -- are you going to be at LPC? > We have no plan to going to attend LPC temporarily. > It's not obvious from this patch where this dependency comes > from...why is SYSVIPC required? I'd like to not have to require IPC_NS > either for devices. Yes, the patch is not highly dependent on SYSVIPC, but it will be convenient if require it. I will update it to drop dependency of it in V2 patch. This patch doesn't need IPC_NS set at present.
RE: [PATCH] binder: ipc namespace support for android binder
>> Hi >> We are working for running android in container, but we found that binder >> is >> not isolated by ipc namespace. Since binder is a form of IPC and therefore >> should >> be tied to ipc namespace. With this patch, we can run more than one android >> container on one host. >> This patch move "binder_procs" and "binder_context" into ipc_namespace, >> driver will find the context from it when opening. Althought statistics in >> debugfs >> remain global. >> >> Signed-off-by: choury zhou >> --- >> drivers/android/Kconfig | 2 +- >> drivers/android/binder.c | 126 +- >> include/linux/ipc_namespace.h | 14 >> ipc/namespace.c | 4 ++ >> 4 files changed, 111 insertions(+), 35 deletions(-) >> >> diff --git a/drivers/android/Kconfig b/drivers/android/Kconfig >> index 432e9ad77070..09883443b2da 100644 >> --- a/drivers/android/Kconfig >> +++ b/drivers/android/Kconfig >> @@ -10,7 +10,7 @@ if ANDROID >> >> config ANDROID_BINDER_IPC >> bool "Android Binder IPC Driver" >> - depends on MMU >> + depends on MMU && SYSVIPC > > NAK. We can't force SYSVIPC on for Android. The notion of running > binder in a container is reasonable, but needs to be done without > explicit requirement for SYSVIPC. binder-in-container is a topic in > the android microconf at Linux plumbers -- are you going to be at LPC? > We have no plan to going to attend LPC temporarily. > It's not obvious from this patch where this dependency comes > from...why is SYSVIPC required? I'd like to not have to require IPC_NS > either for devices. Yes, the patch is not highly dependent on SYSVIPC, but it will be convenient if require it. I will update it to drop dependency of it in V2 patch. This patch doesn't need IPC_NS set at present.
Re: [PATCH 0/9] Analogix ANX6345 RGB-(e)DP bridge support
On Thu, Oct 18, 2018 at 12:35 AM Icenowy Zheng wrote:
>
> This patchset brings the support for Analogix ANX6345 RGB-(e)DP bridge,
> which is used by some Allwinner A64 laptops, such as Pinebook and Olimex
> TERES-I.
>
> It reuses some definitions from the ANX78xx driver that already exists
> in the kernel tree, but the driver code itself is rewritten, because the
> big difference between ANX6345 and ANX78xx.
>
> This patchset also enables the bridge on Pinebook and TERES-I, and a
> temporary workaround patch (do not merge) for the dot clock accuracy
> problem of sun4i-drm.
>
> This patchset assumes some fixes ([1], [2] and [3]) are already
> applied, without them the patchset cannot be tested on the A64 devices
> mentioned above.
For whole series:
Tested-by: Vasily Khoruzhick
>
> [1] https://patchwork.kernel.org/patch/10628827/
> [2] https://patchwork.kernel.org/patch/10628825/
> [3] https://patchwork.kernel.org/patch/10646791/
>
> Chen-Yu Tsai (1):
> [DO NOT MERGE] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency
> check
>
> Icenowy Zheng (8):
> drm/bridge: move ANA78xx driver to analogix subdirectory
> drm/bridge: split some definitions of ANX78xx to dedicated headers
> drm/bridge: extract some Analogix I2C DP common code
> dt-bindings: Add ANX6345 DP/eDP transmitter binding
> drm/bridge: Add Analogix anx6345 support
> arm64: allwinner: a64: add pinmux for RGB666 LCD
> arm64: allwinner: a64: enable ANX6345 bridge on Pinebook
> arm64: allwinner: a64: enable ANX6345 bridge on TERES-I
>
> .../bindings/display/bridge/anx6345.txt | 39 +
> .../dts/allwinner/sun50i-a64-pinebook.dts | 43 +
> .../boot/dts/allwinner/sun50i-a64-teres-i.dts | 40 +-
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 9 +
> drivers/gpu/drm/bridge/Kconfig| 10 -
> drivers/gpu/drm/bridge/Makefile | 4 +-
> drivers/gpu/drm/bridge/analogix-anx78xx.h | 719 ---
> drivers/gpu/drm/bridge/analogix/Kconfig | 25 +
> drivers/gpu/drm/bridge/analogix/Makefile | 4 +
> .../drm/bridge/analogix/analogix-anx6345.c| 862 ++
> .../bridge/{ => analogix}/analogix-anx78xx.c | 146 +--
> .../drm/bridge/analogix/analogix-anx78xx.h| 265 ++
> .../drm/bridge/analogix/analogix-i2c-dptx.c | 169
> .../drm/bridge/analogix/analogix-i2c-dptx.h | 258 ++
> .../bridge/analogix/analogix-i2c-txcommon.h | 240 +
> drivers/gpu/drm/sun4i/sun4i_rgb.c | 5 +-
> 16 files changed, 1956 insertions(+), 882 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/anx6345.txt
> delete mode 100644 drivers/gpu/drm/bridge/analogix-anx78xx.h
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> rename drivers/gpu/drm/bridge/{ => analogix}/analogix-anx78xx.c (90%)
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h
>
> --
> 2.18.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH 0/9] Analogix ANX6345 RGB-(e)DP bridge support
On Thu, Oct 18, 2018 at 12:35 AM Icenowy Zheng wrote:
>
> This patchset brings the support for Analogix ANX6345 RGB-(e)DP bridge,
> which is used by some Allwinner A64 laptops, such as Pinebook and Olimex
> TERES-I.
>
> It reuses some definitions from the ANX78xx driver that already exists
> in the kernel tree, but the driver code itself is rewritten, because the
> big difference between ANX6345 and ANX78xx.
>
> This patchset also enables the bridge on Pinebook and TERES-I, and a
> temporary workaround patch (do not merge) for the dot clock accuracy
> problem of sun4i-drm.
>
> This patchset assumes some fixes ([1], [2] and [3]) are already
> applied, without them the patchset cannot be tested on the A64 devices
> mentioned above.
For whole series:
Tested-by: Vasily Khoruzhick
>
> [1] https://patchwork.kernel.org/patch/10628827/
> [2] https://patchwork.kernel.org/patch/10628825/
> [3] https://patchwork.kernel.org/patch/10646791/
>
> Chen-Yu Tsai (1):
> [DO NOT MERGE] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency
> check
>
> Icenowy Zheng (8):
> drm/bridge: move ANA78xx driver to analogix subdirectory
> drm/bridge: split some definitions of ANX78xx to dedicated headers
> drm/bridge: extract some Analogix I2C DP common code
> dt-bindings: Add ANX6345 DP/eDP transmitter binding
> drm/bridge: Add Analogix anx6345 support
> arm64: allwinner: a64: add pinmux for RGB666 LCD
> arm64: allwinner: a64: enable ANX6345 bridge on Pinebook
> arm64: allwinner: a64: enable ANX6345 bridge on TERES-I
>
> .../bindings/display/bridge/anx6345.txt | 39 +
> .../dts/allwinner/sun50i-a64-pinebook.dts | 43 +
> .../boot/dts/allwinner/sun50i-a64-teres-i.dts | 40 +-
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 9 +
> drivers/gpu/drm/bridge/Kconfig| 10 -
> drivers/gpu/drm/bridge/Makefile | 4 +-
> drivers/gpu/drm/bridge/analogix-anx78xx.h | 719 ---
> drivers/gpu/drm/bridge/analogix/Kconfig | 25 +
> drivers/gpu/drm/bridge/analogix/Makefile | 4 +
> .../drm/bridge/analogix/analogix-anx6345.c| 862 ++
> .../bridge/{ => analogix}/analogix-anx78xx.c | 146 +--
> .../drm/bridge/analogix/analogix-anx78xx.h| 265 ++
> .../drm/bridge/analogix/analogix-i2c-dptx.c | 169
> .../drm/bridge/analogix/analogix-i2c-dptx.h | 258 ++
> .../bridge/analogix/analogix-i2c-txcommon.h | 240 +
> drivers/gpu/drm/sun4i/sun4i_rgb.c | 5 +-
> 16 files changed, 1956 insertions(+), 882 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/anx6345.txt
> delete mode 100644 drivers/gpu/drm/bridge/analogix-anx78xx.h
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> rename drivers/gpu/drm/bridge/{ => analogix}/analogix-anx78xx.c (90%)
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h
>
> --
> 2.18.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH] ptp: drop redundant kasprintf() to create worker name
From: Rasmus Villemoes Date: Fri, 26 Oct 2018 23:22:59 +0200 > Building with -Wformat-nonliteral, gcc complains > > drivers/ptp/ptp_clock.c: In function ‘ptp_clock_register’: > drivers/ptp/ptp_clock.c:239:26: warning: format not a string literal and no > format arguments [-Wformat-nonliteral] > worker_name : info->name); > > kthread_create_worker takes fmt+varargs to set the name of the > worker, and that happens with a vsnprintf() to a stack buffer (that is > then copied into task_comm). So there's no reason not to just pass > "ptp%d", ptp->index to kthread_create_worker() and avoid the > intermediate worker_name variable. > > Signed-off-by: Rasmus Villemoes Applied.
Re: [PATCH] ptp: drop redundant kasprintf() to create worker name
From: Rasmus Villemoes Date: Fri, 26 Oct 2018 23:22:59 +0200 > Building with -Wformat-nonliteral, gcc complains > > drivers/ptp/ptp_clock.c: In function ‘ptp_clock_register’: > drivers/ptp/ptp_clock.c:239:26: warning: format not a string literal and no > format arguments [-Wformat-nonliteral] > worker_name : info->name); > > kthread_create_worker takes fmt+varargs to set the name of the > worker, and that happens with a vsnprintf() to a stack buffer (that is > then copied into task_comm). So there's no reason not to just pass > "ptp%d", ptp->index to kthread_create_worker() and avoid the > intermediate worker_name variable. > > Signed-off-by: Rasmus Villemoes Applied.
Re: linux-next: build failure in Linus' tree
From: Linus Torvalds
Date: Sun, 28 Oct 2018 15:45:16 -0700
> On Sun, Oct 28, 2018 at 3:35 PM Stephen Rothwell
> wrote:
>>
>> After merging the origin tree, today's linux-next build (powerpc
>> ppc64_defconfig) failed like this:
>
> linux-next is back! Wheee..
>
>> 5a2de63fd1a5 ("bridge: do not add port to router list when receives query
>> with source 0.0.0.0")
>
> David?
I'm on it and have a fix coming.
Re: linux-next: build failure in Linus' tree
From: Linus Torvalds
Date: Sun, 28 Oct 2018 15:45:16 -0700
> On Sun, Oct 28, 2018 at 3:35 PM Stephen Rothwell
> wrote:
>>
>> After merging the origin tree, today's linux-next build (powerpc
>> ppc64_defconfig) failed like this:
>
> linux-next is back! Wheee..
>
>> 5a2de63fd1a5 ("bridge: do not add port to router list when receives query
>> with source 0.0.0.0")
>
> David?
I'm on it and have a fix coming.
[PATCHv2] mm/page_owner: use kvmalloc instead of kmalloc
From: Miles Chen The kbuf used by page owner is allocated by kmalloc(), which means it can use only normal memory and there might be a "out of memory" issue when we're out of normal memory. Use kvmalloc() so we can also allocate kbuf from normal/hihghmem on 32bit kernel. Clamp the kbuf size to PAGE_SIZE. Change since v1: - use kvmalloc() - clamp buffer size to PAGE_SIZE Signed-off-by: Miles Chen Cc: Joe Perches Cc: Matthew Wilcox Cc: Michal Hocko --- mm/page_owner.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/mm/page_owner.c b/mm/page_owner.c index d80adfe..a064cd0 100644 --- a/mm/page_owner.c +++ b/mm/page_owner.c @@ -1,7 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 #include #include -#include #include #include #include @@ -351,7 +350,8 @@ void pagetypeinfo_showmixedcount_print(struct seq_file *m, .skip = 0 }; - kbuf = kmalloc(count, GFP_KERNEL); + count = count > PAGE_SIZE ? PAGE_SIZE : count; + kbuf = kvmalloc(count, GFP_KERNEL); if (!kbuf) return -ENOMEM; @@ -397,11 +397,11 @@ void pagetypeinfo_showmixedcount_print(struct seq_file *m, if (copy_to_user(buf, kbuf, ret)) ret = -EFAULT; - kfree(kbuf); + kvfree(kbuf); return ret; err: - kfree(kbuf); + kvfree(kbuf); return -ENOMEM; } -- 1.9.1
[PATCHv2] mm/page_owner: use kvmalloc instead of kmalloc
From: Miles Chen The kbuf used by page owner is allocated by kmalloc(), which means it can use only normal memory and there might be a "out of memory" issue when we're out of normal memory. Use kvmalloc() so we can also allocate kbuf from normal/hihghmem on 32bit kernel. Clamp the kbuf size to PAGE_SIZE. Change since v1: - use kvmalloc() - clamp buffer size to PAGE_SIZE Signed-off-by: Miles Chen Cc: Joe Perches Cc: Matthew Wilcox Cc: Michal Hocko --- mm/page_owner.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/mm/page_owner.c b/mm/page_owner.c index d80adfe..a064cd0 100644 --- a/mm/page_owner.c +++ b/mm/page_owner.c @@ -1,7 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 #include #include -#include #include #include #include @@ -351,7 +350,8 @@ void pagetypeinfo_showmixedcount_print(struct seq_file *m, .skip = 0 }; - kbuf = kmalloc(count, GFP_KERNEL); + count = count > PAGE_SIZE ? PAGE_SIZE : count; + kbuf = kvmalloc(count, GFP_KERNEL); if (!kbuf) return -ENOMEM; @@ -397,11 +397,11 @@ void pagetypeinfo_showmixedcount_print(struct seq_file *m, if (copy_to_user(buf, kbuf, ret)) ret = -EFAULT; - kfree(kbuf); + kvfree(kbuf); return ret; err: - kfree(kbuf); + kvfree(kbuf); return -ENOMEM; } -- 1.9.1
Re: bnx2: rx_fw_discards: BCM5716 sporadically drops packets when update to driver version 2.2.6
Could anyone give some clues to address count of rx_fw_discards increasing issue? On 2018/10/26 11:15, maowenan wrote: > Hi， > > After I update version of bnx2 driver from 2.2.1 to 2.2.6, I find BCM5716 > sporadically drops packets, which > shows in rx_fw_discards. > C36-141-5:~ # ethtool -S NIC0 > > NIC statistics: > rx_ucast_packets: 11902 > > rx_mcast_packets: 217 > > rx_bcast_packets: 4954320 > > rx_filtered_packets: 328793 > > rx_fw_discards: 2742 > > C36-141-5:~ # > > 5s later: > > C36-141-5:~ # ethtool -S NIC0 > > NIC statistics: > rx_ucast_packets: 11910 > > rx_mcast_packets: 217 > > rx_bcast_packets: 4958117 > > rx_filtered_packets: 328897 > > rx_fw_discards: 2750 > > C36-141-5:~ # > > so rx_fw_discards: 2742-> rx_fw_discards: 2750, lost 8 packets. > > the information of bnx2 > C36-141-5:~ # modinfo bnx2 > kernel/drivers/net/ethernet/broadcom/bnx2.ko > > firmware: bnx2/bnx2-rv2p-09ax-6.0.17.fw > > firmware: bnx2/bnx2-rv2p-09-6.0.17.fw > > firmware: bnx2/bnx2-mips-09-6.2.1b.fw > > firmware: bnx2/bnx2-rv2p-06-6.0.15.fw > > firmware: bnx2/bnx2-mips-06-6.2.3.fw > version:2.2.6 > > > 1) Firstly, I check the patches from 2.2.1 to 2.2.6, below patch is > interesting. > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0021850d0417a4dc38ed871d929b651b87e2ead9 > Do not enable filter SORT MODE in chip init routine. This patch addresses an > issue where BCM5716 sporadically drops packets when changing multicast list. > > diff --git a/drivers/net/ethernet/broadcom/bnx2.c > b/drivers/net/ethernet/broadcom/bnx2.c > index 8957eb5f4478..8c9a8b7787d2 100644 > --- a/drivers/net/ethernet/broadcom/bnx2.c > +++ b/drivers/net/ethernet/broadcom/bnx2.c > @@ -4984,8 +4984,6 @@ bnx2_init_chip(struct bnx2 *bp) > > bp->idle_chk_status_idx = 0x; > > - bp->rx_mode = BNX2_EMAC_RX_MODE_SORT_MODE; > - > /* Set up how to generate a link change interrupt. */ > BNX2_WR(bp, BNX2_EMAC_ATTENTION_ENA, BNX2_EMAC_ATTENTION_ENA_LINK); > > > 2) Secondly, I revert this patch, after verify it, I find rx_fw_discards does > not increasing. > so I think this patch can fix current issue. But I'm not sure the issue of > this patch to fix > will be reproduced? > I'm not convinced that what factor will trigger rx_fw_discards increasing? > And how to fix this? > > Thanks a lot. > > > > > > > > > > > > > > . >
Re: bnx2: rx_fw_discards: BCM5716 sporadically drops packets when update to driver version 2.2.6
Could anyone give some clues to address count of rx_fw_discards increasing issue? On 2018/10/26 11:15, maowenan wrote: > Hi， > > After I update version of bnx2 driver from 2.2.1 to 2.2.6, I find BCM5716 > sporadically drops packets, which > shows in rx_fw_discards. > C36-141-5:~ # ethtool -S NIC0 > > NIC statistics: > rx_ucast_packets: 11902 > > rx_mcast_packets: 217 > > rx_bcast_packets: 4954320 > > rx_filtered_packets: 328793 > > rx_fw_discards: 2742 > > C36-141-5:~ # > > 5s later: > > C36-141-5:~ # ethtool -S NIC0 > > NIC statistics: > rx_ucast_packets: 11910 > > rx_mcast_packets: 217 > > rx_bcast_packets: 4958117 > > rx_filtered_packets: 328897 > > rx_fw_discards: 2750 > > C36-141-5:~ # > > so rx_fw_discards: 2742-> rx_fw_discards: 2750, lost 8 packets. > > the information of bnx2 > C36-141-5:~ # modinfo bnx2 > kernel/drivers/net/ethernet/broadcom/bnx2.ko > > firmware: bnx2/bnx2-rv2p-09ax-6.0.17.fw > > firmware: bnx2/bnx2-rv2p-09-6.0.17.fw > > firmware: bnx2/bnx2-mips-09-6.2.1b.fw > > firmware: bnx2/bnx2-rv2p-06-6.0.15.fw > > firmware: bnx2/bnx2-mips-06-6.2.3.fw > version:2.2.6 > > > 1) Firstly, I check the patches from 2.2.1 to 2.2.6, below patch is > interesting. > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0021850d0417a4dc38ed871d929b651b87e2ead9 > Do not enable filter SORT MODE in chip init routine. This patch addresses an > issue where BCM5716 sporadically drops packets when changing multicast list. > > diff --git a/drivers/net/ethernet/broadcom/bnx2.c > b/drivers/net/ethernet/broadcom/bnx2.c > index 8957eb5f4478..8c9a8b7787d2 100644 > --- a/drivers/net/ethernet/broadcom/bnx2.c > +++ b/drivers/net/ethernet/broadcom/bnx2.c > @@ -4984,8 +4984,6 @@ bnx2_init_chip(struct bnx2 *bp) > > bp->idle_chk_status_idx = 0x; > > - bp->rx_mode = BNX2_EMAC_RX_MODE_SORT_MODE; > - > /* Set up how to generate a link change interrupt. */ > BNX2_WR(bp, BNX2_EMAC_ATTENTION_ENA, BNX2_EMAC_ATTENTION_ENA_LINK); > > > 2) Secondly, I revert this patch, after verify it, I find rx_fw_discards does > not increasing. > so I think this patch can fix current issue. But I'm not sure the issue of > this patch to fix > will be reproduced? > I'm not convinced that what factor will trigger rx_fw_discards increasing? > And how to fix this? > > Thanks a lot. > > > > > > > > > > > > > > . >
