On Sat, Aug 29, 2020 at 1:40 PM Guenter Roeck wrote:
>
> Except for
>
> CHECK: spaces preferred around that '+' (ctx:VxV)
> #29: FILE: drivers/dma/fsldma.h:223:
> + u32 val_lo = in_be32((u32 __iomem *)addr+1);
Added spaces.
> I don't see anything wrong with it either, so
>
> Reviewed-by: G
On 8/29/20 10:29 AM, Linus Torvalds wrote:
> On Sat, Aug 29, 2020 at 5:46 AM Luc Van Oostenryck
> wrote:
>>
>> But the pointer is already 32-bit, so simply cast the pointer to u32.
>
> Yeah, that code was completely pointless. If the pointer had actually
> been 64-bit, the old code would have war
On Sat, Aug 29, 2020 at 5:46 AM Luc Van Oostenryck
wrote:
>
> But the pointer is already 32-bit, so simply cast the pointer to u32.
Yeah, that code was completely pointless. If the pointer had actually
been 64-bit, the old code would have warned too.
The odd thing is that the fsl_iowrite64() fun
Le 29/08/2020 à 17:05, Guenter Roeck a écrit :
On Sat, Aug 29, 2020 at 02:45:38PM +0200, Luc Van Oostenryck wrote:
For ppc32, the functions fsl_ioread64() & fsl_ioread64be()
use lower_32_bits() as a fancy way to cast the pointer to u32
in order to do non-atomic 64-bit IO.
But the pointer is
On Sat, Aug 29, 2020 at 02:45:38PM +0200, Luc Van Oostenryck wrote:
> For ppc32, the functions fsl_ioread64() & fsl_ioread64be()
> use lower_32_bits() as a fancy way to cast the pointer to u32
> in order to do non-atomic 64-bit IO.
>
> But the pointer is already 32-bit, so simply cast the pointer
For ppc32, the functions fsl_ioread64() & fsl_ioread64be()
use lower_32_bits() as a fancy way to cast the pointer to u32
in order to do non-atomic 64-bit IO.
But the pointer is already 32-bit, so simply cast the pointer to u32.
This fixes a compile error introduced by
ef91bb196b0d ("kernel.h:
Add missing MODULE_DESCRIPTION.
Signed-off-by: YueHaibing
---
drivers/net/wan/fsl_ucc_hdlc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
index 9edd94679283..dca97cd7c4e7 100644
--- a/drivers/net/wan/fsl_ucc_hdlc.c
+++ b/driv
On Thu, Aug 27, 2020 at 11:15:12AM -0700, Linus Torvalds wrote:
> > SYM_FUNC_START(__put_user_2)
> > - ENTER
> > - mov TASK_addr_limit(%_ASM_BX),%_ASM_BX
> > + LOAD_TASK_SIZE_MAX
> > sub $1,%_ASM_BX
>
> It's even more obvious here. We load a constant and then immediately
On Thu, Aug 27, 2020 at 11:06:28AM -0700, Linus Torvalds wrote:
> On Thu, Aug 27, 2020 at 8:00 AM Christoph Hellwig wrote:
> >
> > Once we can't manipulate the address limit, we also can't test what
> > happens when the manipulation is abused.
>
> Just remove these tests entirely.
>
> Once set_f
On Thu, Aug 27, 2020 at 03:58:02PM +, David Laight wrote:
> Is there a real justification for that?
> For system calls supplying both methods makes sense to avoid
> the extra code paths for a simple read/write.
Al asked for it as two of our four in-tree instances do have weird
semantics, and w
10 matches
Mail list logo
