On powerpc64, -mprofile-kernel results in two instructions being
emitted: 'mflr r0' and 'bl _mcount'. So far, we were only nop'ing out
the branch to _mcount(). This series implements an approach to also nop
out the preceding mflr.
Patches 1-3 are generic changes. Patch 2 is a fix for x86, but
While over-riding ftrace_replace_code(), we still want to reuse the
existing __ftrace_replace_code() function. Rename the function and
make it available for other kernel code.
Signed-off-by: Naveen N. Rao
---
include/linux/ftrace.h | 1 +
kernel/trace/ftrace.c | 8
2 files changed, 5
On 5/17/19 10:39 AM, Paul Walmsley wrote:
On Wed, 1 May 2019, Atish Patra wrote:
Currently, last stage boot loaders such as U-Boot can accept only
uImage which is an unnecessary additional step in automating boot flows.
Add a PE/COFF compliant image header that boot loaders can parse and
On Fri, May 17, 2019 at 02:51:17PM -0400, Joe Lawrence wrote:
> Miroslav reported that the livepatch self-tests were failing,
> specifically a case in which the consistency model ensures that we do
> not patch a current executing function, "TEST: busy target module".
>
> Recent renovations to
On Fri, May 17, 2019 at 11:23:36PM +0530, Vidya Sagar wrote:
> On 5/17/2019 6:54 PM, Bjorn Helgaas wrote:
> > Do you have "lspci -vvxxx" output for the root ports handy?
> >
> > If there's some clue in the standard config space that would tell us
> > that MSI works for some events but not others,
> On May 17, 2019, at 11:21 AM, Sean Christopherson
> wrote:
>
>> On Fri, May 17, 2019 at 11:04:22AM -0700, Linus Torvalds wrote:
>> On Fri, May 17, 2019 at 10:55 AM Sean Christopherson
>> wrote:
>>>
>>> In this snippet, IS_PRIVATE() is true for anon inodes, false for
>>> /dev/sgx/enclave.
On Fri, May 17, 2019 at 11:33:30AM -0700, Linus Torvalds wrote:
> On Fri, May 17, 2019 at 11:21 AM Sean Christopherson
> wrote:
> >
> > I agree that conceptually EPC is private memory, but because EPC is
> > managed as a separate memory pool, SGX tags it VM_PFNMAP and manually
> > inserts PFNs,
Miroslav reported that the livepatch self-tests were failing,
specifically a case in which the consistency model ensures that we do
not patch a current executing function, "TEST: busy target module".
Recent renovations to stack_trace_save_tsk_reliable() left it returning
only an -ERRNO success
Hi Steven,
On Fri, May 17, 2019 at 6:47 PM Steven Rostedt wrote:
>
> Hi Miguel,
>
> Linus mentioned this too.
>
>
> https://lore.kernel.org/lkml/CAHk-=wihyb8w__yqjgyjyzsvniu5ctktcfycmcgdqvg8guj...@mail.gmail.com/T/#u
Ah, I didn't see that. We were discussing here [1] backporting to 4.19
some
On 5/17/19 1:33 PM, Arnd Bergmann wrote:
> On Fri, May 17, 2019 at 8:08 PM Alex Elder wrote:
>>
>> On 5/15/19 2:34 AM, Arnd Bergmann wrote:
+static void gsi_trans_tre_fill(struct gsi_tre *dest_tre, dma_addr_t addr,
+ u32 len, bool last_tre, bool bei,
+
+Alexei, Daniel, and bpf
> On May 17, 2019, at 2:10 AM, Peter Zijlstra wrote:
>
> On Fri, May 17, 2019 at 04:15:39PM +0800, Kairui Song wrote:
>> Hi, I think the actual problem is that bpf_get_stackid_tp (and maybe
>> some other bfp functions) is now broken, or, strating an unwind
>> directly
On Fri, May 17, 2019 at 11:21 AM Sean Christopherson
wrote:
>
> I agree that conceptually EPC is private memory, but because EPC is
> managed as a separate memory pool, SGX tags it VM_PFNMAP and manually
> inserts PFNs, i.e. EPC effectively it gets classified as IO memory.
>
> And
The pull request you sent on Fri, 17 May 2019 16:32:10 +0800:
> ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/greentime/linux.git
> tags/nds32-for-linus-5.2-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/4489da7183099f569a7d3dd819c975073c04bc72
Thank
Hi,
On Thu, May 16, 2019 at 6:53 PM Rob Clark wrote:
>
> From: Rob Clark
>
> This is essentialy a squash of a bunch of history of cheza dt updates
> from chromium kernel, some of which were themselves squashes of history
> from older chromium kernels.
>
> I don't claim any credit other than
The pull request you sent on Fri, 17 May 2019 08:58:54 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux tags/s390-5.2-2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/80111bfb672d8c04d60c25559243554f732f2848
Thank you!
--
Deet-doot-dot, I am a bot.
The pull request you sent on Fri, 17 May 2019 04:11:26 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git fixes
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/bf8a9a4755737f6630756f0d87bea9b38f0ed369
Thank you!
--
Deet-doot-dot, I am a bot.
The pull request you sent on Fri, 17 May 2019 05:59:36 +0200:
> https://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c011d23ba046826ccf8c4a4a6c1d01c9ccaa1403
Thank you!
--
Deet-doot-dot, I am a bot.
On Fri, May 17, 2019 at 8:55 AM Dmitry Vyukov wrote:
>
> On Fri, May 17, 2019 at 5:51 PM Dmitry Vyukov wrote:
> > > > >
> > > > > From: Dmitry Vyukov
> > > > > Date: Fri, May 17, 2019 at 3:26 AM
> > > > > To: Greg Kroah-Hartman, Arve Hjønnevåg, Todd Kjos, Martijn Coenen,
> > > > > Joel
This change supports nand-ecc-step-size and nand-ecc-strenght fields in
brcmnand dt node to be optional.
see: Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
If both nand-ecc-strength and nand-ecc-step-size are not specified in
device tree node for NAND, nand_base driver does detect onfi
On Fri, May 17, 2019 at 8:08 PM Alex Elder wrote:
>
> On 5/15/19 2:34 AM, Arnd Bergmann wrote:
> >> +static void gsi_trans_tre_fill(struct gsi_tre *dest_tre, dma_addr_t addr,
> >> + u32 len, bool last_tre, bool bei,
> >> + enum
nand-ecc-strength and nand-ecc-step-size can be made optional as
brcmanand driver can support using the nand_base driver detected
values.
Signed-off-by: Kamal Dasu
---
Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
On May 17, 2019 2:23:10 PM GMT-03:00, Ivan Babrou wrote:
>On Fri, May 17, 2019 at 8:22 AM Arnaldo Carvalho de Melo
> wrote:
>>
>> Em Fri, May 17, 2019 at 11:01:45AM +0200, Miguel Ojeda escreveu:
>> > On Fri, May 17, 2019 at 10:51 AM Greg KH
> wrote:
>> > >
>> > > On Fri, May 17, 2019 at
On Fri, May 17, 2019 at 11:04:22AM -0700, Linus Torvalds wrote:
> On Fri, May 17, 2019 at 10:55 AM Sean Christopherson
> wrote:
> >
> > In this snippet, IS_PRIVATE() is true for anon inodes, false for
> > /dev/sgx/enclave. Because EPC memory is always shared, SELinux will never
> > check
On Thu, 2019-05-16 at 22:08 -0600, Jane Chu wrote:
> Some user who install SIGBUS handler that does longjmp out
> therefore keeping the process alive is confused by the error
> message
> "[188988.765862] Memory failure: 0x1840200: Killing
>cellsrv:33395 due to hardware memory corruption"
>
On 5/17/19 1:50 PM, Sean Christopherson wrote:
On Fri, May 17, 2019 at 01:42:50PM -0400, Stephen Smalley wrote:
On 5/17/19 1:29 PM, Sean Christopherson wrote:
AIUI, having FILE__WRITE and FILE__EXECUTE on /dev/sgx/enclave would allow
*any* enclave/process to map EPC as RWX. Moving to anon
On Fri, May 17, 2019 at 10:55 AM Sean Christopherson
wrote:
>
> In this snippet, IS_PRIVATE() is true for anon inodes, false for
> /dev/sgx/enclave. Because EPC memory is always shared, SELinux will never
> check PROCESS__EXECMEM for mprotect() on/dev/sgx/enclave.
Why _does_ the memory have to
Hi Dan,
Thank you very much for your review, my comments below:
On Mon, May 6, 2019 at 2:01 PM Dan Williams wrote:
>
> On Mon, May 6, 2019 at 10:57 AM Dave Hansen wrote:
> >
> > > -static inline void remove_memory(int nid, u64 start, u64 size) {}
> > > +static inline bool remove_memory(int
On 5/15/19 2:34 AM, Arnd Bergmann wrote:
>> +static void gsi_trans_tre_fill(struct gsi_tre *dest_tre, dma_addr_t addr,
>> + u32 len, bool last_tre, bool bei,
>> + enum ipa_cmd_opcode opcode)
>> +{
>> + struct gsi_tre tre;
>> +
>> +
On 2019-05-17 11:27, Alex Elder wrote:
On 5/15/19 8:09 PM, Subash Abhinov Kasiviswanathan wrote:
. . .
Hi Alex
Could we instead have the rmnet header definition in
include/linux/if_rmnet.h
I have no objection to that, but I don't actually know what
the criteria are for putting a file in that
On Fri, May 17, 2019 at 07:48:17PM +0200, Borislav Petkov wrote:
> @@ -1562,15 +1567,21 @@ static void __mcheck_cpu_init_generic(void)
> static void __mcheck_cpu_init_clear_banks(void)
> {
> struct mce_bank *mce_banks = this_cpu_read(mce_banks_array);
> + u64 msrval;
> int i;
>
On 5/17/19 1:12 PM, Andy Lutomirski wrote:
On May 17, 2019, at 9:37 AM, Stephen Smalley wrote:
On 5/17/19 12:20 PM, Stephen Smalley wrote:
On 5/17/19 11:09 AM, Sean Christopherson wrote:
On Fri, May 17, 2019 at 09:53:06AM -0400, Stephen Smalley wrote:
On 5/16/19 6:23 PM, Xing, Cedric
On 2019-05-16 11:29, Aaro Koskinen wrote:
Hi,
On Wed, May 08, 2019 at 06:47:12PM -0700, Prasad Sodagudi wrote:
Some platforms may need warm reboot support when kernel crashed
for post mortem analysis instead of cold reboot. So use config
CONFIG_WARM_REBOOT_ON_PANIC and SYSTEM_RESET2 psci
On Fri, May 17, 2019 at 01:49:05PM -0400, Liming Sun wrote:
> This commit adds the ABI definitions exposed to userspace for
> the platform/mellanox/mlxbf-bootctl driver.
>
> Reviewed-by: Vadim Pasternak
> Signed-off-by: Liming Sun
> ---
> .../ABI/testing/sysfs-platform-mellanox-bootctl| 58
> > - local_inc(>nest);
> > + rb->nest++;
> > + barrier();
> Urgh; almost but not quite. You just lost the 'volatile' qualifier and
> now the compiler can mess things up for you.
I thought the barriers added could force the compiler to forget what it knows
about rb->nest, and do the write
On Fri, May 17, 2019 at 2:25 AM Miguel Ojeda
wrote:
>
> + memset((char *)(iter) + offsetof(struct trace_iterator, seq), 0,
> + sizeof(struct trace_iterator) -
> + offsetof(struct trace_iterator, seq));
Honestly, the above is nasty.
Whenever you have to split an
On Fri, May 17, 2019 at 10:43:01AM -0700, Andy Lutomirski wrote:
>
> > On May 17, 2019, at 10:29 AM, Sean Christopherson
> > wrote:
> >
> > AIUI, having FILE__WRITE and FILE__EXECUTE on /dev/sgx/enclave would allow
> > *any* enclave/process to map EPC as RWX. Moving to anon inodes and thus
>
On 5/17/2019 6:54 PM, Bjorn Helgaas wrote:
On Fri, May 17, 2019 at 01:49:49PM +0530, Vidya Sagar wrote:
On 5/16/2019 7:04 PM, Bjorn Helgaas wrote:
On Tue, May 14, 2019 at 09:00:19AM +0530, Vidya Sagar wrote:
On 5/13/2019 12:55 PM, Christoph Hellwig wrote:
On Mon, May 13, 2019 at 10:36:13AM
Thanks Andy!
v5 has been posted to address all the comments. You could also see the detailed
response below.
Regards,
Liming
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org
> On Behalf Of Andy Shevchenko
> Sent: Tuesday, February 5, 2019 12:22 PM
> To: Liming Sun
>
On Thu, May 16, 2019 at 09:32:06PM -0700, Ankur Arora wrote:
> On 2019-05-15 1:43 p.m., Marcelo Tosatti wrote:
> >On Wed, May 15, 2019 at 11:42:56AM -0700, Ankur Arora wrote:
> >>On 5/14/19 6:50 AM, Marcelo Tosatti wrote:
> >>>On Mon, May 13, 2019 at 05:20:37PM +0800, Wanpeng Li wrote:
> On
On Fri, May 17, 2019 at 01:42:50PM -0400, Stephen Smalley wrote:
> On 5/17/19 1:29 PM, Sean Christopherson wrote:
> >AIUI, having FILE__WRITE and FILE__EXECUTE on /dev/sgx/enclave would allow
> >*any* enclave/process to map EPC as RWX. Moving to anon inodes and thus
> >PROCESS__EXECMEM achieves
These changes solve a warning realated to an incorrect type inilizer in the
function
fieldbus_poll.
Signed-off-by: Oscar Gomez Fuente
---
drivers/staging/fieldbus/dev_core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/fieldbus/dev_core.c
This commit adds the ABI definitions exposed to userspace for
the platform/mellanox/mlxbf-bootctl driver.
Reviewed-by: Vadim Pasternak
Signed-off-by: Liming Sun
---
.../ABI/testing/sysfs-platform-mellanox-bootctl| 58 ++
MAINTAINERS
This commit adds the bootctl platform driver for Mellanox BlueField
Soc, which controls the eMMC boot partition swapping and sends SMC
calls to ATF running at exception level EL3 to program some system
register. This register is persistent during warm reset and is only
accessible in secure code
On Fri, May 17, 2019 at 10:26:49AM -0700, Luck, Tony wrote:
> Which is a quirk for some models where we don't want to do
> the "write all 1s and see what sticks"
Ok, then we have to do what you suggested yesterday. I've added a short
comment so that I don't get lost again next time.
---
diff
> On May 17, 2019, at 10:29 AM, Sean Christopherson
> wrote:
>
>> On Fri, May 17, 2019 at 12:37:40PM -0400, Stephen Smalley wrote:
>>> On 5/17/19 12:20 PM, Stephen Smalley wrote:
On 5/17/19 11:09 AM, Sean Christopherson wrote:
I think we may want to change the SGX API to alloc an
On 5/17/19 1:29 PM, Sean Christopherson wrote:
On Fri, May 17, 2019 at 12:37:40PM -0400, Stephen Smalley wrote:
On 5/17/19 12:20 PM, Stephen Smalley wrote:
On 5/17/19 11:09 AM, Sean Christopherson wrote:
I think we may want to change the SGX API to alloc an anon inode for each
enclave instead
On 5/17/2019 6:33 PM, Ard Biesheuvel wrote:
On Fri, 17 May 2019 at 14:41, Vidya Sagar wrote:
Add P2U (PIPE to UPHY) and PCIe controller nodes to device tree.
The Tegra194 SoC contains six PCIe controllers and twenty P2U instances
grouped into two different PHY bricks namely High-Speed IO
On Fri, May 17, 2019 at 4:49 AM Paolo Bonzini wrote:
>
> Ouch, thanks. :/ I'll send a new pull request as soon as I finish
> testing the change you suggested.
I see that you added the trivial fix to things and re-tagged using the
same tag name. I've pulled it,
Linus
On Wed, 1 May 2019, Atish Patra wrote:
> Currently, last stage boot loaders such as U-Boot can accept only
> uImage which is an unnecessary additional step in automating boot flows.
>
> Add a PE/COFF compliant image header that boot loaders can parse and
> directly load kernel flat Image. The
On Fri 17 May 09:47 PDT 2019, Stephen Boyd wrote:
> This patch series implements a read-only version of memremap() via
> a new MEMREMAP_RO flag. If this is passed in the mapping call, we'll
> try to map the memory region as read-only if it doesn't intersect
> with an existing mapping. Otherwise,
On Fri, May 17, 2019 at 1:24 PM Pavel Tatashin
wrote:
>
> On Fri, May 17, 2019 at 1:22 PM Pavel Tatashin
> wrote:
> >
> > On Fri, May 17, 2019 at 10:38 AM Michal Hocko wrote:
> > >
> > > On Fri 17-05-19 10:20:38, Pavel Tatashin wrote:
> > > > This panic is unrelated to circular lock issue that
On Fri, May 17, 2019 at 12:37:40PM -0400, Stephen Smalley wrote:
> On 5/17/19 12:20 PM, Stephen Smalley wrote:
> >On 5/17/19 11:09 AM, Sean Christopherson wrote:
> >>I think we may want to change the SGX API to alloc an anon inode for each
> >>enclave instead of hanging every enclave off of the
On Fri, May 17, 2019 at 8:57 AM Kees Cook wrote:
>
> On Fri, May 17, 2019 at 08:08:27AM -0700, Dan Williams wrote:
> > As far as I can see it's mostly check_heap_object() that is the
> > problem, so I'm open to finding a way to just bypass that sub-routine.
> > However, as far as I can see none
On Fri, May 17, 2019 at 3:36 PM Maxime Ripard wrote:
>
> On Fri, May 17, 2019 at 01:51:56AM +0800, Frank Lee wrote:
> > > > +struct sun50i_thermal_chip {
> > > > + int sensor_num;
> > > > + int offset;
> > > > + int scale;
> > > > + int ft_deviation;
> > > > +
On 5/15/19 8:09 PM, Subash Abhinov Kasiviswanathan wrote:
. . .
> Hi Alex
>
> Could we instead have the rmnet header definition in
> include/linux/if_rmnet.h
I have no objection to that, but I don't actually know what
the criteria are for putting a file in that directory.
Glancing at other
On Fri, May 17, 2019 at 06:37:29PM +0200, Borislav Petkov wrote:
> Now, the
>
> wrmsrl(msr_ops.ctl(i), -1)
> rdmsrl(msr_ops.ctl(i), val);
>
> method of throwing all 1s to see what sticks is what Intel wants, as
> Tony said. Is that going to be a problem on AMD?
It is what we want in
On Fri, May 17, 2019 at 1:22 PM Pavel Tatashin
wrote:
>
> On Fri, May 17, 2019 at 10:38 AM Michal Hocko wrote:
> >
> > On Fri 17-05-19 10:20:38, Pavel Tatashin wrote:
> > > This panic is unrelated to circular lock issue that I reported in a
> > > separate thread, that also happens during memory
On Fri, May 17, 2019 at 8:33 AM Dmitry Vyukov wrote:
>
> On Fri, May 17, 2019 at 5:26 PM Todd Kjos wrote:
> >
> > Yes (and syzbot seemed to confirm the fix). I didn't realize I needed
> > to manually close the issue. I guess you closed it yesterday.
>
> This is required to auto-close the bug
On Fri, May 17, 2019 at 8:22 AM Arnaldo Carvalho de Melo
wrote:
>
> Em Fri, May 17, 2019 at 11:01:45AM +0200, Miguel Ojeda escreveu:
> > On Fri, May 17, 2019 at 10:51 AM Greg KH wrote:
> > >
> > > On Fri, May 17, 2019 at 10:35:29AM +0200, Miguel Ojeda wrote:
> > > > On Fri, May 17, 2019 at 9:38
On Fri, May 17, 2019 at 10:38 AM Michal Hocko wrote:
>
> On Fri 17-05-19 10:20:38, Pavel Tatashin wrote:
> > This panic is unrelated to circular lock issue that I reported in a
> > separate thread, that also happens during memory hotremove.
> >
> > xakep ~/x/linux$ git describe
> >
If the system has other devices being registered in the component
framework, the compare function will be called with a device that
doesn't belong to vimc.
This device is not necessarily a platform_device, nor have a
platform_data (which causes a NULL pointer dereference error) and if it
does have
On Fri, May 17, 2019 at 3:32 PM Maxime Ripard wrote:
>
> On Fri, May 17, 2019 at 02:10:47AM +0800, Frank Lee wrote:
> > > On Sun, May 12, 2019 at 11:41:28PM +0200, Ondřej Jirman wrote:
> > > > > > +static int tsens_get_temp(void *data, int *temp)
> > > > > > +{
> > > > > > + struct tsensor *s =
> On May 17, 2019, at 9:37 AM, Stephen Smalley wrote:
>
>> On 5/17/19 12:20 PM, Stephen Smalley wrote:
>>> On 5/17/19 11:09 AM, Sean Christopherson wrote:
On Fri, May 17, 2019 at 09:53:06AM -0400, Stephen Smalley wrote:
> On 5/16/19 6:23 PM, Xing, Cedric wrote:
> I thought
On Wed, Apr 24, 2019 at 12:18 AM Vineeth Remanan Pillai
wrote:
>
> From: Peter Zijlstra (Intel)
>
> Not-Signed-off-by: Peter Zijlstra (Intel)
> ---
> kernel/sched/core.c | 38 +-
> 1 file changed, 37 insertions(+), 1 deletion(-)
>
> diff --git
From: Dmitry Vyukov
in_softirq() is a wrong predicate to check if we are in a softirq context.
It also returns true if we have BH disabled, so objects are falsely
stamped with "softirq" comm. The correct predicate is in_serving_softirq().
Signed-off-by: Dmitry Vyukov
Cc: linux...@kvack.org
Cc:
On Fri, May 17, 2019 at 06:53:11PM +0200, Oscar Gomez Fuente wrote:
> Signed-off-by: Oscar Gomez Fuente
> ---
> drivers/staging/fieldbus/dev_core.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
I don't take patches without any changelog text, sorry.
Please fix and resend.
On 5/13/2019 4:20 AM, Sibi Sankar wrote:
Re-worked the macros of the rpmpd driver. Add power domains support
for QCS404 and MSM8998.
For the series:
Reviewed-by: Jeffrey Hugo
V4:
* fixup fixes tag and commit message in patch 1 [Marc]
* fixup typos in qcs404 and msm8998 dt nodes
* fixup
This patch adds support for an alternative method to add xattrs to files in
the rootfs filesystem. Instead of extracting them directly from the ram
disk image, they are extracted from a regular file called .xattr-list, that
can be added by any ram disk generator available today. The file format
From: Mimi Zohar
This patch adds xattrs to a file, with name and value taken from a supplied
buffer. The data format is:
\0
[kamensky: fixed restoring of xattrs for symbolic links by using
sys_lsetxattr() instead of sys_setxattr()]
[sassu: removed state management, kept only
This patch set aims at solving the following use case: appraise files from
the initial ram disk. To do that, IMA checks the signature/hash from the
security.ima xattr. Unfortunately, this use case cannot be implemented
currently, as the CPIO format does not support xattrs.
This proposal consists
On 17.05.2019 18:01, Arnaldo Carvalho de Melo wrote:
> Em Wed, May 15, 2019 at 06:44:29PM +0300, Alexey Budankov escreveu:
>> On 15.05.2019 15:59, Arnaldo Carvalho de Melo wrote:
>>> Em Wed, May 15, 2019 at 11:43:30AM +0300, Alexey Budankov escreveu:
On 15.05.2019 0:46, Arnaldo Carvalho de
Cc Linus Walleij and leds-g...@vger.kernel.org.
On 5/16/19 11:42 PM, Kun Yi wrote:
*** BLURB HERE ***
Hello there,
I recently tested ledtrig-gpio on an embedded controller and one of the
issues I had involve not requesting the user input pin as GPIO.
In many embedded systems, a pin could be
On Sat, May 18, 2019 at 1:10 AM Masahiro Yamada
wrote:
>
> In the recent build test of linux-next, Stephen saw a build error
> caused by a broken .tmp_versions/*.mod file:
>
> https://lkml.org/lkml/2019/5/13/991
>
> drivers/net/phy/asix.ko and drivers/net/usb/asix.ko have the same
> basename,
Signed-off-by: Oscar Gomez Fuente
---
drivers/staging/fieldbus/dev_core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/fieldbus/dev_core.c
b/drivers/staging/fieldbus/dev_core.c
index 60b851406..f6f5b92 100644
--- a/drivers/staging/fieldbus/dev_core.c
This gets rid of some duplicate code, and also makes the reserved memory
region show up as 'cmd-db' memory in /proc/iomem.
Cc: Evan Green
Cc: Rob Herring
Cc: Bjorn Andersson
Cc: Andy Gross
Cc: Will Deacon
Cc: Catalin Marinas
Cc: Dan Williams
Signed-off-by: Stephen Boyd
---
Sometimes we have memories that are supposed to be read-only, but when
we map these regions the best we can do is map them as write-back with
MEMREMAP_WB. Introduce a read-only memory mapping (MEMREMAP_RO) that
allows us to map reserved memory regions as read-only. This way, we're
less likely to
We have a few drivers that need to get a reserved memory region, request
the region, and map the reserved memory with memremap(). Add an API to
do this all in one function call.
Cc: Evan Green
Cc: Rob Herring
Cc: Bjorn Andersson
Cc: Andy Gross
Cc: Will Deacon
Cc: Catalin Marinas
Cc: Dan
Pass in PAGE_KERNEL_RO to the underlying IO mapping mechanism to get a
read-only mapping for the MEMREMAP_RO type of memory mappings that
memremap() supports.
Cc: Evan Green
Cc: Rob Herring
Cc: Bjorn Andersson
Cc: Andy Gross
Cc: Will Deacon
Cc: Catalin Marinas
Cc: Dan Williams
The command DB is read-only already to the kernel because everything is
const marked once we map it. Let's go one step further and try to map
the memory as read-only in the page tables. This should make it harder
for random code to corrupt the database and change the contents.
Cc: Evan Green
Cc:
This patch series implements a read-only version of memremap() via
a new MEMREMAP_RO flag. If this is passed in the mapping call, we'll
try to map the memory region as read-only if it doesn't intersect
with an existing mapping. Otherwise, we'll try to fallback to other
flags to try to map the
On Fri, 17 May 2019 11:25:02 +0200
Miguel Ojeda wrote:
> Starting with GCC 9, -Warray-bounds detects cases when memset is called
> starting on a member of a struct but the size to be cleared ends up
> writing over further members.
>
> Such a call happens in the trace code to clear, at once, all
Hi Ted,
On Wed, May 15, 2019 at 6:57 AM Theodore Ts'o wrote:
> Ah, I think I see the problem. Sorry, this one was my fault. Does
> this fix things for you?
Thanks!
Sorry for missing this patch in the thread before.
> From 0c72924ef346d54e8627440e6d71257aa5b56105 Mon Sep 17 00:00:00 2001
>
On Fri, May 17, 2019 at 04:14:03PM +, David Laight wrote:
> From: Kees Cook
> > Sent: 17 May 2019 16:54
> ...
> > > I've changed some of our code to use __get_user() to avoid
> > > these stupid overheads.
> >
> > __get_user() skips even access_ok() checking too, so that doesn't seem
> > like
On 5/17/19 12:20 PM, Stephen Smalley wrote:
On 5/17/19 11:09 AM, Sean Christopherson wrote:
On Fri, May 17, 2019 at 09:53:06AM -0400, Stephen Smalley wrote:
On 5/16/19 6:23 PM, Xing, Cedric wrote:
I thought EXECMOD applied to files (and memory mappings backed by
them) but
I was probably
On Fri, May 17, 2019 at 03:46:07PM +, Ghannam, Yazen wrote:
> I think there are a couple of issues here.
> 1) The bank is being initialized without accounting for any quirks.
Almost. __mcheck_cpu_init_clear_banks() a little bit later corrects
that. I guess I can drop the
On the Arm Juno platform, the HDLCD pixel clock is constrained to 250KHz
resolution in order to avoid the tiny System Control Processor spending
aeons trying to calculate exact PLL coefficients. This means that modes
like my oddball 1600x1200 with 130.89MHz clock get rejected since the
rate cannot
HI,
On Fri, May 17, 2019 at 2:29 AM Ondřej Jirman wrote:
>
> Hi Yangtao,
>
> thank you for work on this driver.
>
> On Fri, May 17, 2019 at 02:06:53AM +0800, Frank Lee wrote:
> > HI Ondřej,
> >
> > On Mon, May 13, 2019 at 6:16 AM Ondřej Jirman wrote:
> > > > +
> > > > +/* Temp Unit: millidegree
> On May 17, 2019, at 1:10 AM, Peter Zijlstra wrote:
>
> On Fri, May 17, 2019 at 09:46:00AM +0200, Peter Zijlstra wrote:
>> On Thu, May 16, 2019 at 11:51:55PM +, Song Liu wrote:
>>> Hi,
>>>
>>> We found a failure with selftests/bpf/tests_prog in test_stacktrace_map (on
>>> bpf/master
If maintainers are okay with this then,
Reviewed-by: Chaitanya Kulkarni
On 5/17/19 12:07 AM, xiaolinkui wrote:
> Use struct_size() to keep code sample.
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end,
On 5/17/19 11:09 AM, Sean Christopherson wrote:
On Fri, May 17, 2019 at 09:53:06AM -0400, Stephen Smalley wrote:
On 5/16/19 6:23 PM, Xing, Cedric wrote:
I thought EXECMOD applied to files (and memory mappings backed by them) but
I was probably wrong. It sounds like EXECMOD applies to the whole
On 10/05/2019 13:29, Amit Kucheria wrote:
> From: "Raju P.L.S.S.S.N"
>
> Add device bindings for cpuidle states for cpu devices.
>
> [amit: rename the idle-states to more generic names and fixups]
>
> Cc:
> Cc:
> Signed-off-by: Raju P.L.S.S.S.N
> Reviewed-by: Evan Green
> Signed-off-by:
On Fri, May 17, 2019 at 2:34 PM Stephen Rothwell wrote:
>
> Hi Masahiro,
>
> Thanks for this, looks good to me. Just a nit below.
>
> On Fri, 17 May 2019 13:27:53 +0900 Masahiro Yamada
> wrote:
> >
>
> > diff --git a/scripts/modules-check.sh b/scripts/modules-check.sh
> > new file mode 100755
> On May 17, 2019, at 9:20 AM, Stephen Smalley wrote:
>
>> On 5/17/19 11:09 AM, Sean Christopherson wrote:
>>> On Fri, May 17, 2019 at 09:53:06AM -0400, Stephen Smalley wrote:
On 5/16/19 6:23 PM, Xing, Cedric wrote:
I thought EXECMOD applied to files (and memory mappings backed by
> On May 17, 2019, at 1:32 AM, Kairui Song wrote:
>
> On Fri, May 17, 2019 at 4:15 PM Kairui Song wrote:
>>
>> On Fri, May 17, 2019 at 4:11 PM Peter Zijlstra wrote:
>>>
>>> On Fri, May 17, 2019 at 09:46:00AM +0200, Peter Zijlstra wrote:
On Thu, May 16, 2019 at 11:51:55PM +, Song
On Fri, May 17, 2019 at 2:46 PM Lucas De Marchi
wrote:
>
> On Thu, May 16, 2019 at 10:37 PM Greg KH wrote:
> >
> > On Fri, May 17, 2019 at 01:45:11PM +0900, Masahiro Yamada wrote:
> > > On Fri, May 17, 2019 at 1:29 PM Masahiro Yamada
> > > wrote:
> > > >
> > > > In the recent build test of
Dear friend,
I’m Mr mohammad ouattara, Manager of bill and exchange at (BOA) BANK
in Burkina Faso, I would like you to indicate your interest to receive
the transfer of (15.5 Million Dollars) in your bank account, I will
like you to stand as the next of kin to a deceased customer who die in
plane
Julien Grall writes ("qcom_scm: Incompatible pointer type build failure"):
> Thank you for the report.
...>
> On 30/04/2019 13:44, Ian Jackson wrote:
> > osstest service owner writes ("[linux-4.19 test] 135420: regressions -
> > FAIL"):
> >drivers/firmware/qcom_scm.c: In function
From: Kees Cook
> Sent: 17 May 2019 16:54
...
> > I've changed some of our code to use __get_user() to avoid
> > these stupid overheads.
>
> __get_user() skips even access_ok() checking too, so that doesn't seem
> like a good idea. Did you run access_ok() checks separately? (This
> generally
Running a graphics adapter on the MACCHIATObin fails due to an
insufficently sized memory window.
Enlarge the memory window for the PCIe slot to 512 MiB.
With the patch I am able to use a GT710 graphics adapter with 1 GB onboard
memory.
These are the mapped memory areas that the graphics
On 10/05/2019 13:29, Amit Kucheria wrote:
> Add device bindings for cpuidle states for cpu devices.
>
> Cc: Marc Gonzalez
> Signed-off-by: Amit Kucheria
Acked-by: Daniel Lezcano
> ---
> arch/arm64/boot/dts/qcom/msm8998.dtsi | 32 +++
> 1 file changed, 32
201 - 300 of 617 matches
Mail list logo
