![[BACK]](/icons/back.gif){kind=icon}
Up to [cvs.NetBSD.org] / src / sys / dev / marvell
Request diff between arbitrary revisions
Default branch: MAIN
Revision 1.18 / (download) - annotate - [select for diffs], Sat Dec 31 21:15:20 2022 UTC (5 weeks ago) by andvar
Branch: MAIN
CVS Tags: HEAD
Changes since 1.17: +4 -4
lines
Diff to previous 1.17 (colored)
fix few typos in comments.
Revision 1.17 / (download) - annotate - [select for diffs], Fri Jul 8 07:02:47 2022 UTC (6 months, 4 weeks ago) by skrll
Branch: MAIN
CVS Tags: netbsd-10-base,
netbsd-10,
bouyer-sunxi-drm-base,
bouyer-sunxi-drm
Changes since 1.16: +2 -2
lines
Diff to previous 1.16 (colored)
alredy -> already
Revision 1.16 / (download) - annotate - [select for diffs], Wed Jun 1 15:40:15 2022 UTC (8 months ago) by riastradh
Branch: MAIN
Changes since 1.15: +2 -4
lines
Diff to previous 1.15 (colored)
mvxpsec(4): Fix missing change to freesession return type. Not sure how this didn't get committed before -- it was supposed to be part of this change: https://mail-index.netbsd.org/source-changes/2022/05/22/msg138764.html
Revision 1.15 / (download) - annotate - [select for diffs], Sun May 22 11:38:51 2022 UTC (8 months, 2 weeks ago) by riastradh
Branch: MAIN
Changes since 1.14: +6 -14
lines
Diff to previous 1.14 (colored)
mvxpsec(4): Prune dead branches. Assert session id validity.
Revision 1.14 / (download) - annotate - [select for diffs], Tue Apr 12 21:05:37 2022 UTC (9 months, 3 weeks ago) by andvar
Branch: MAIN
Changes since 1.13: +2 -2
lines
Diff to previous 1.13 (colored)
s/sould/should/ and s/shoud/should/
Revision 1.13 / (download) - annotate - [select for diffs], Sat Apr 9 23:38:32 2022 UTC (9 months, 3 weeks ago) by riastradh
Branch: MAIN
Changes since 1.12: +3 -3
lines
Diff to previous 1.12 (colored)
sys: Use membar_release/acquire around reference drop. This just goes through my recent reference count membar audit and changes membar_exit to membar_release and membar_enter to membar_acquire -- this should make everything cheaper on most CPUs without hurting correctness, because membar_acquire is generally cheaper than membar_enter.
Revision 1.12 / (download) - annotate - [select for diffs], Wed Apr 6 22:48:09 2022 UTC (9 months, 4 weeks ago) by riastradh
Branch: MAIN
Changes since 1.11: +32 -34
lines
Diff to previous 1.11 (colored)
mvxpsec(4): Nix trailing whitespace.
Revision 1.11 / (download) - annotate - [select for diffs], Sat Mar 12 15:32:32 2022 UTC (10 months, 3 weeks ago) by riastradh
Branch: MAIN
Changes since 1.10: +5 -2
lines
Diff to previous 1.10 (colored)
sys: Membar audit around reference count releases. If two threads are using an object that is freed when the reference count goes to zero, we need to ensure that all memory operations related to the object happen before freeing the object. Using an atomic_dec_uint_nv(&refcnt) == 0 ensures that only one thread takes responsibility for freeing, but it's not enough to ensure that the other thread's memory operations happen before the freeing. Consider: Thread A Thread B obj->foo = 42; obj->baz = 73; mumble(&obj->bar); grumble(&obj->quux); /* membar_exit(); */ /* membar_exit(); */ atomic_dec -- not last atomic_dec -- last /* membar_enter(); */ KASSERT(invariant(obj->foo, obj->bar)); free_stuff(obj); The memory barriers ensure that obj->foo = 42; mumble(&obj->bar); in thread A happens before KASSERT(invariant(obj->foo, obj->bar)); free_stuff(obj); in thread B. Without them, this ordering is not guaranteed. So in general it is necessary to do membar_exit(); if (atomic_dec_uint_nv(&obj->refcnt) != 0) return; membar_enter(); to release a reference, for the `last one out hit the lights' style of reference counting. (This is in contrast to the style where one thread blocks new references and then waits under a lock for existing ones to drain with a condvar -- no membar needed thanks to mutex(9).) I searched for atomic_dec to find all these. Obviously we ought to have a better abstraction for this because there's so much copypasta. This is a stop-gap measure to fix actual bugs until we have that. It would be nice if an abstraction could gracefully handle the different styles of reference counting in use -- some years ago I drafted an API for this, but making it cover everything got a little out of hand (particularly with struct vnode::v_usecount) and I ended up setting it aside to work on psref/localcount instead for better scalability. I got bored of adding #ifdef __HAVE_ATOMIC_AS_MEMBAR everywhere, so I only put it on things that look performance-critical on 5sec review. We should really adopt membar_enter_preatomic/membar_exit_postatomic or something (except they are applicable only to atomic r/m/w, not to atomic_load/store_*, making the naming annoying) and get rid of all the ifdefs.
Revision 1.10 / (download) - annotate - [select for diffs], Sat Feb 12 03:24:36 2022 UTC (11 months, 3 weeks ago) by riastradh
Branch: MAIN
Changes since 1.9: +2 -2
lines
Diff to previous 1.9 (colored)
sys: Fix various abuse of struct device internals. Will help to make struct device opaque later.
Revision 1.9 / (download) - annotate - [select for diffs], Fri Dec 10 20:36:04 2021 UTC (13 months, 3 weeks ago) by andvar
Branch: MAIN
Changes since 1.8: +2 -2
lines
Diff to previous 1.8 (colored)
s/occured/occurred/ in comments, log messages and man pages.
Revision 1.8 / (download) - annotate - [select for diffs], Fri Aug 13 20:26:07 2021 UTC (17 months, 3 weeks ago) by andvar
Branch: MAIN
Changes since 1.7: +2 -2
lines
Diff to previous 1.7 (colored)
s/struture/structure/ s/structre/structure/
Revision 1.7 / (download) - annotate - [select for diffs], Sat Jul 25 22:37:48 2020 UTC (2 years, 6 months ago) by riastradh
Branch: MAIN
CVS Tags: thorpej-i2c-spi-conf2-base,
thorpej-i2c-spi-conf2,
thorpej-i2c-spi-conf-base,
thorpej-i2c-spi-conf,
thorpej-futex2-base,
thorpej-futex2,
thorpej-futex-base,
thorpej-futex,
thorpej-cfargs2-base,
thorpej-cfargs2,
thorpej-cfargs-base,
thorpej-cfargs,
cjep_sun2x-base1,
cjep_sun2x-base,
cjep_sun2x,
cjep_staticlib_x-base1,
cjep_staticlib_x-base,
cjep_staticlib_x
Changes since 1.6: +12 -1
lines
Diff to previous 1.6 (colored)
Make this build with or without options IPSEC. Not really that useful without options IPSEC, but simply uncommenting mvxpsec in conf/ARMADAXP didn't build, and this change is trivial, so why not.
Revision 1.6 / (download) - annotate - [select for diffs], Sat Jul 25 22:37:16 2020 UTC (2 years, 6 months ago) by riastradh
Branch: MAIN
Changes since 1.5: +1 -3
lines
Diff to previous 1.5 (colored)
Omit needless rijndael dependencies.
Revision 1.2.6.2 / (download) - annotate - [select for diffs], Mon Apr 13 08:04:23 2020 UTC (2 years, 9 months ago) by martin
Branch: phil-wifi
Changes since 1.2.6.1: +2 -12
lines
Diff to previous 1.2.6.1 (colored) to branchpoint 1.2 (colored) next main 1.3 (colored)
Mostly merge changes from HEAD upto 20200411
Revision 1.2.6.1 / (download) - annotate - [select for diffs], Wed Apr 8 14:08:07 2020 UTC (2 years, 9 months ago) by martin
Branch: phil-wifi
Changes since 1.2: +3 -3
lines
Diff to previous 1.2 (colored)
Merge changes from current as of 20200406
Revision 1.5 / (download) - annotate - [select for diffs], Fri Dec 27 09:41:51 2019 UTC (3 years, 1 month ago) by msaitoh
Branch: MAIN
CVS Tags: phil-wifi-20200421,
phil-wifi-20200411,
phil-wifi-20200406,
is-mlppp-base,
is-mlppp,
bouyer-xenpvh-base2,
bouyer-xenpvh-base1,
bouyer-xenpvh-base,
bouyer-xenpvh,
ad-namecache-base3,
ad-namecache-base2,
ad-namecache-base1,
ad-namecache-base,
ad-namecache
Changes since 1.4: +2 -2
lines
Diff to previous 1.4 (colored)
s/transfered/transferred/
Revision 1.4 / (download) - annotate - [select for diffs], Fri Dec 27 07:41:23 2019 UTC (3 years, 1 month ago) by msaitoh
Branch: MAIN
Changes since 1.3: +2 -2
lines
Diff to previous 1.3 (colored)
s/opration/operation/
Revision 1.3 / (download) - annotate - [select for diffs], Tue Oct 15 00:13:53 2019 UTC (3 years, 3 months ago) by chs
Branch: MAIN
CVS Tags: phil-wifi-20191119
Changes since 1.2: +3 -13
lines
Diff to previous 1.2 (colored)
convert more KM_NOSLEEP to KM_SLEEP and remove code to handle failures.
Revision 1.1.12.1 / (download) - annotate - [select for diffs], Tue Feb 27 09:07:32 2018 UTC (4 years, 11 months ago) by martin
Branch: netbsd-8
CVS Tags: netbsd-8-2-RELEASE,
netbsd-8-1-RELEASE,
netbsd-8-1-RC1,
netbsd-8-0-RELEASE,
netbsd-8-0-RC2,
netbsd-8-0-RC1
Changes since 1.1: +3 -3
lines
Diff to previous 1.1 (colored) next main 1.2 (colored)
Pull up following revision(s) (requested by mrg in ticket #593): sys/dev/marvell/mvxpsec.c: revision 1.2 sys/arch/m68k/m68k/pmap_motorola.c: revision 1.70 sys/opencrypto/crypto.c: revision 1.102 sys/arch/sparc64/sparc64/pmap.c: revision 1.308 sys/ufs/chfs/chfs_malloc.c: revision 1.5 sys/arch/powerpc/oea/pmap.c: revision 1.95 sys/sys/pool.h: revision 1.80,1.82 sys/kern/subr_pool.c: revision 1.209-1.216,1.219-1.220 sys/arch/alpha/alpha/pmap.c: revision 1.262 sys/kern/uipc_mbuf.c: revision 1.173 sys/uvm/uvm_fault.c: revision 1.202 sys/sys/mbuf.h: revision 1.172 sys/kern/subr_extent.c: revision 1.86 sys/arch/x86/x86/pmap.c: revision 1.266 (via patch) sys/dev/dtv/dtv_scatter.c: revision 1.4 Allow only one pending call to a pool's backing allocator at a time. Candidate fix for problems with hanging after kva fragmentation related to PR kern/45718. Proposed on tech-kern: https://mail-index.NetBSD.org/tech-kern/2017/10/23/msg022472.html Tested by bouyer@ on i386. This makes one small change to the semantics of pool_prime and pool_setlowat: they may fail with EWOULDBLOCK instead of ENOMEM, if there is a pending call to the backing allocator in another thread but we are not actually out of memory. That is unlikely because nearly always these are used during initialization, when the pool is not in use. Define the new flag too for previous commit. pool_grow can now fail even when sleeping is ok. Catch this case in pool_get and retry. Assert that pool_get failure happens only with PR_NOWAIT. This would have caught the mistake I made last week leading to null pointer dereferences all over the place, a mistake which I evidently poorly scheduled alongside maxv's change to the panic message on x86 for null pointer dereferences. Since pr_lock is now used to wait for two things now (PR_GROWING and PR_WANTED) we need to loop for the condition we wanted. make the KASSERTMSG/panic strings consistent as '%s: [%s], __func__, wchan' Handle the ERESTART case from pool_grow() don't pass 0 to the pool flags Guess pool_cache_get(pc, 0) means PR_WAITOK here. Earlier on in the same context we use kmem_alloc(sz, KM_SLEEP). use PR_WAITOK everywhere. use PR_NOWAIT. Don't use 0 for PR_NOWAIT use PR_NOWAIT instead of 0 panic ex nihilo -- PR_NOWAITing for zerot Add assertions that either PR_WAITOK or PR_NOWAIT are set. - fix an assert; we can reach there if we are nowait or limitfail. - when priming the pool and failing with ERESTART, don't decrement the number of pages; this avoids the issue of returning an ERESTART when we get to 0, and is more correct. - simplify the pool_grow code, and don't wakeup things if we ENOMEM. In pmap_enter_ma(), only try to allocate pves if we might need them, and even if that fails, only fail the operation if we later discover that we really do need them. This implements the requirement that pmap_enter(PMAP_CANFAIL) must not fail when replacing an existing mapping with the first mapping of a new page, which is an unintended consequence of the changes from the rmind-uvmplock branch in 2011. The problem arises when pmap_enter(PMAP_CANFAIL) is used to replace an existing pmap mapping with a mapping of a different page (eg. to resolve a copy-on-write). If that fails and leaves the old pmap entry in place, then UVM won't hold the right locks when it eventually retries. This entanglement of the UVM and pmap locking was done in rmind-uvmplock in order to improve performance, but it also means that the UVM state and pmap state need to be kept in sync more than they did before. It would be possible to handle this in the UVM code instead of in the pmap code, but these pmap changes improve the handling of low memory situations in general, and handling this in UVM would be clunky, so this seemed like the better way to go. This somewhat indirectly fixes PR 52706, as well as the failing assertion about "uvm_page_locked_p(old_pg)". (but only on x86, various other platforms will need their own changes to handle this issue.) In uvm_fault_upper_enter(), if pmap_enter(PMAP_CANFAIL) fails, assert that the pmap did not leave around a now-stale pmap mapping for an old page. If such a pmap mapping still existed after we unlocked the vm_map, the UVM code would not know later that it would need to lock the lower layer object while calling the pmap to remove or replace that stale pmap mapping. See PR 52706 for further details. hopefully workaround the irregularly "fork fails in init" problem. if a pool is growing, and the grower is PR_NOWAIT, mark this. if another caller wants to grow the pool and is also PR_NOWAIT, busy-wait for the original caller, which should either succeed or hard-fail fairly quickly. implement the busy-wait by unlocking and relocking this pools mutex and returning ERESTART. other methods (such as having the caller do this) were significantly more code and this hack is fairly localised. ok chs@ riastradh@ Don't release the lock in the PR_NOWAIT allocation. Move flags setting after the acquiring the mutex. (from Tobias Nygren) apply the change from arch/x86/x86/pmap.c rev. 1.266 commitid vZRjvmxG7YTHLOfA: In pmap_enter_ma(), only try to allocate pves if we might need them, and even if that fails, only fail the operation if we later discover that we really do need them. If we are replacing an existing mapping, reuse the pv structure where possible. This implements the requirement that pmap_enter(PMAP_CANFAIL) must not fail when replacing an existing mapping with the first mapping of a new page, which is an unintended consequence of the changes from the rmind-uvmplock branch in 2011. The problem arises when pmap_enter(PMAP_CANFAIL) is used to replace an existing pmap mapping with a mapping of a different page (eg. to resolve a copy-on-write). If that fails and leaves the old pmap entry in place, then UVM won't hold the right locks when it eventually retries. This entanglement of the UVM and pmap locking was done in rmind-uvmplock in order to improve performance, but it also means that the UVM state and pmap state need to be kept in sync more than they did before. It would be possible to handle this in the UVM code instead of in the pmap code, but these pmap changes improve the handling of low memory situations in general, and handling this in UVM would be clunky, so this seemed like the better way to go. This somewhat indirectly fixes PR 52706 on the remaining platforms where this problem existed.
Revision 1.2.2.2 / (download) - annotate - [select for diffs], Sun Dec 3 11:37:05 2017 UTC (5 years, 2 months ago) by jdolecek
Branch: tls-maxphys
Changes since 1.2.2.1: +3690 -0
lines
Diff to previous 1.2.2.1 (colored) to branchpoint 1.2 (colored) next main 1.3 (colored)
update from HEAD
Revision 1.2.2.1, Thu Nov 9 22:22:58 2017 UTC (5 years, 2 months ago) by jdolecek
Branch: tls-maxphys
Changes since 1.2: +0 -3690
lines
FILE REMOVED
file mvxpsec.c was added on branch tls-maxphys on 2017-12-03 11:37:05 +0000
Revision 1.2 / (download) - annotate - [select for diffs], Thu Nov 9 22:22:58 2017 UTC (5 years, 2 months ago) by christos
Branch: MAIN
CVS Tags: tls-maxphys-base-20171202,
phil-wifi-base,
phil-wifi-20190609,
pgoyette-compat-merge-20190127,
pgoyette-compat-base,
pgoyette-compat-20190127,
pgoyette-compat-20190118,
pgoyette-compat-1226,
pgoyette-compat-1126,
pgoyette-compat-1020,
pgoyette-compat-0930,
pgoyette-compat-0906,
pgoyette-compat-0728,
pgoyette-compat-0625,
pgoyette-compat-0521,
pgoyette-compat-0502,
pgoyette-compat-0422,
pgoyette-compat-0415,
pgoyette-compat-0407,
pgoyette-compat-0330,
pgoyette-compat-0322,
pgoyette-compat-0315,
pgoyette-compat,
netbsd-9-base,
netbsd-9-3-RELEASE,
netbsd-9-2-RELEASE,
netbsd-9-1-RELEASE,
netbsd-9-0-RELEASE,
netbsd-9-0-RC2,
netbsd-9-0-RC1,
netbsd-9,
jdolecek-ncqfixes-base,
jdolecek-ncqfixes,
isaki-audio2-base,
isaki-audio2
Branch point for: tls-maxphys,
phil-wifi
Changes since 1.1: +3 -3
lines
Diff to previous 1.1 (colored)
use PR_NOWAIT instead of 0
Revision 1.1.2.2 / (download) - annotate - [select for diffs], Sat Jun 6 14:40:08 2015 UTC (7 years, 8 months ago) by skrll
Branch: nick-nhusb
Changes since 1.1.2.1: +3690 -0
lines
Diff to previous 1.1.2.1 (colored) to branchpoint 1.1 (colored) next main 1.2 (colored)
Sync with HEAD
Revision 1.1.2.1, Wed Jun 3 04:20:02 2015 UTC (7 years, 8 months ago) by skrll
Branch: nick-nhusb
Changes since 1.1: +0 -3690
lines
FILE REMOVED
file mvxpsec.c was added on branch nick-nhusb on 2015-06-06 14:40:08 +0000
Revision 1.1 / (download) - annotate - [select for diffs], Wed Jun 3 04:20:02 2015 UTC (7 years, 8 months ago) by hsuenaga
Branch: MAIN
CVS Tags: prg-localcount2-base3,
prg-localcount2-base2,
prg-localcount2-base1,
prg-localcount2-base,
prg-localcount2,
pgoyette-localcount-base,
pgoyette-localcount-20170426,
pgoyette-localcount-20170320,
pgoyette-localcount-20170107,
pgoyette-localcount-20161104,
pgoyette-localcount-20160806,
pgoyette-localcount-20160726,
pgoyette-localcount,
perseant-stdc-iso10646-base,
perseant-stdc-iso10646,
nick-nhusb-base-20170825,
nick-nhusb-base-20170204,
nick-nhusb-base-20161204,
nick-nhusb-base-20161004,
nick-nhusb-base-20160907,
nick-nhusb-base-20160529,
nick-nhusb-base-20160422,
nick-nhusb-base-20160319,
nick-nhusb-base-20151226,
nick-nhusb-base-20150921,
nick-nhusb-base-20150606,
netbsd-8-base,
matt-nb8-mediatek-base,
matt-nb8-mediatek,
localcount-20160914,
jdolecek-ncq-base,
jdolecek-ncq,
bouyer-socketcan-base1,
bouyer-socketcan-base,
bouyer-socketcan
Branch point for: nick-nhusb,
netbsd-8
add new cryptographic accelerator driver 'mvxpsec.' this driver controls CESA unit as same as mvcesa, but uses DMA engines and does CBC operations, HMAC operations by hardware. about 2 kbytes of data are processed at one. supported algorithms are: - DES-CBC, 3DES-CBC, AES-CBC - HMAC-SHA1, HMAC-MD5 non-CBC algorithm such as AES-GCM is not supported by CESA's acceleration engine. mvcesa is still useful to implement such algorithms as combination of accelerated block cipher and software chaining.