Home
last modified time | relevance | path

Searched refs:blame (Results 1 – 16 of 16) sorted by relevance

/OK3568_Linux_fs/buildroot/package/git/
H A D0001-Fix-build-without-threads.patch10 from blame.c:1:
16 from blame.c:1:
21 from blame.c:1:
27 from blame.c:1:
/OK3568_Linux_fs/kernel/drivers/iommu/
H A Dsun50i-iommu.c808 u32 blame; in sun50i_iommu_handle_pt_irq() local
813 blame = iommu_read(iommu, blame_reg); in sun50i_iommu_handle_pt_irq()
814 master = ilog2(blame & IOMMU_INT_MASTER_MASK); in sun50i_iommu_handle_pt_irq()
832 u32 blame; in sun50i_iommu_handle_perm_irq() local
836 blame = iommu_read(iommu, IOMMU_INT_STA_REG); in sun50i_iommu_handle_perm_irq()
837 master = ilog2(blame & IOMMU_INT_MASTER_MASK); in sun50i_iommu_handle_perm_irq()
/OK3568_Linux_fs/kernel/Documentation/process/
H A Dmanagement-style.rst216 4) Placing blame
219 Things will go wrong, and people want somebody to blame. Tag, you're it.
221 It's not actually that hard to accept the blame, especially if people
223 best way of taking the blame: do it for someone else. You'll feel good
235 Taking the blame is also why you get to be manager in the first place.
278 Since your main responsibility seems to be to take the blame for other
H A Dmaintainer-pgp-guide.rst53 shift the blame for potential future security incidents to someone else.
709 .. _`nothing to do with it`: https://github.com/jayphelps/git-blame-someone-else
/OK3568_Linux_fs/yocto/poky/meta/files/common-licenses/
H A DGLWTPL17 TRACE TO TRACK THE AUTHOR of the original product to blame for or hold
/OK3568_Linux_fs/yocto/poky/scripts/contrib/
H A Dpatchreview.py213 analyse(results, want_blame=args.blame, verbose=args.verbose)
/OK3568_Linux_fs/kernel/Documentation/usb/
H A Diuu_phoenix.rst16 guru, so don't blame me if your system is unstable
/OK3568_Linux_fs/kernel/Documentation/driver-api/acpi/
H A Dlinuxized-acpica.rst268 "git blame source/include/acpixf.h" and referencing the line that contains
/OK3568_Linux_fs/kernel/Documentation/admin-guide/
H A Dras.rst191 to blame. So, it has to blame both memory modules.
197 way to know what memory module is to blame. So, it has to blame both
/OK3568_Linux_fs/kernel/Documentation/driver-api/usb/
H A Dpersist.rst161 data corruption and to crash your system. You'll have no one to blame
/OK3568_Linux_fs/yocto/poky/meta/classes/
H A Dkernel-yocto.bbclass501 …ol_why.py', '--dotconfig', '{}'.format( d.getVar('B') + '/.config' ), '--blame', c], cwd=s, env=e…
/OK3568_Linux_fs/kernel/Documentation/driver-api/
H A Dipmi.rst465 interrupts, the driver will run VERY slowly. Don't blame me,
/OK3568_Linux_fs/buildroot/docs/manual/
H A Dcontribute.txt118 Reviewed-by is thus mainly that you are prepared to take the blame on
/OK3568_Linux_fs/kernel/Documentation/translations/it_IT/process/
H A Dmaintainer-pgp-guide.rst702 .. _`non averci niente a che fare`: https://github.com/jayphelps/git-blame-someone-else
/OK3568_Linux_fs/u-boot/tools/buildman/
H A DREADME577 to blame our commits. The bad news is that our commits are not tested on that
/OK3568_Linux_fs/external/xserver/
H A DChangeLog188793 header include. I don't know how this happened, but I'm going to blame
188795 (due to other driver changes that made me not blame dirty for the