linux-stable.git/arch/xtensa/include/uapi/asm, branch v3.18.76

xtensa: provide __NR_sync_file_range2 instead of __NR_sync_file_range

2015-05-17T23:12:17+00:00

[ Upstream commit 01e84c70fe40c8111f960987bcf7f931842e6d07 ]

xtensa actually uses sync_file_range2 implementation, so it should
define __NR_sync_file_range2 as other architectures that use that
function. That fixes userspace interface (that apparently never worked)
and avoids special-casing xtensa in libc implementations.
See the thread ending at
http://lists.busybox.net/pipermail/uclibc/2015-February/048833.html
for more details.

Cc: stable@vger.kernel.org
Signed-off-by: Max Filippov 
Signed-off-by: Sasha Levin

Merge tag 'xtensa-for-next-20141021-1' of git://github.com/jcmvbkbc/linux-xtensa into for_next

2014-10-23T17:30:33+00:00

Xtensa improvements for 3.18:

- add seccomp, getrandom, and memfd_create syscalls;
- add defconfigs for KC705 and SMP LX200;
- fix ISS and xtfpga Kconfig dependencies so that more randconfigs
  are buildable;
- fix umount syscall;
- implement pgprot_noncached.

xtensa: re-wire umount syscall to sys_oldumount

2014-10-21T09:28:41+00:00

Userspace actually passes single parameter (path name) to the umount
syscall, so new umount just fails. Fix it by requesting old umount
syscall implementation and re-wiring umount to it.

Cc: stable@vger.kernel.org
Signed-off-by: Max Filippov

xtensa: add seccomp, getrandom, and memfd_create syscalls

2014-10-05T23:23:52+00:00

Signed-off-by: Max Filippov

xtensa/uapi: Add definition of TIOC[SG]RS485

2014-09-10T06:48:57+00:00

Commit: e676253b19b2d269cccf67fdb1592120a0cd0676 [3/21] serial/8250: Add
support for RS485 IOCTLs, adds support for RS485 ioctls for 825_core on
all the archs. Unfortunaltely the definition of TIOCSRS485 and
TIOCGRS485 was missing on the ioctls.h file

Reported-by: kbuild test robot 
Signed-off-by: Ricardo Ribalda Delgado 
Signed-off-by: Chris Zankel

xtensa: add renameat2 syscall

2014-08-14T07:59:15+00:00

Signed-off-by: Miklos Szeredi 
Cc: Chris Zankel 
Signed-off-by: Max Filippov

xtensa: replace IOCTL code definitions with constants

2014-08-14T07:59:13+00:00

This fixes userspace code that builds on other architectures but fails
on xtensa due to references to structures that other architectures don't
refer to. E.g. this fixes the following issue with python-2.7.8:

  python-2.7.8/Modules/termios.c:861:25: error: invalid application
     of 'sizeof' to incomplete type 'struct serial_multiport_struct'
     {"TIOCSERGETMULTI", TIOCSERGETMULTI},
  python-2.7.8/Modules/termios.c:870:25: error: invalid application
     of 'sizeof' to incomplete type 'struct serial_multiport_struct'
     {"TIOCSERSETMULTI", TIOCSERSETMULTI},
  python-2.7.8/Modules/termios.c:900:24: error: invalid application
     of 'sizeof' to incomplete type 'struct tty_struct'
     {"TIOCTTYGSTRUCT", TIOCTTYGSTRUCT},

Cc: stable@vger.kernel.org
Signed-off-by: Max Filippov

xtensa: wire up sched_setattr and sched_getattr syscalls

2014-02-21T18:37:20+00:00

Signed-off-by: Max Filippov

net: introduce SO_BPF_EXTENSIONS

2014-01-19T03:08:58+00:00

For user space packet capturing libraries such as libpcap, there's
currently only one way to check which BPF extensions are supported
by the kernel, that is, commit aa1113d9f85d ("net: filter: return
-EINVAL if BPF_S_ANC* operation is not supported"). For querying all
extensions at once this might be rather inconvenient.

Therefore, this patch introduces a new option which can be used as
an argument for getsockopt(), and allows one to obtain information
about which BPF extensions are supported by the current kernel.

As David Miller suggests, we do not need to define any bits right
now and status quo can just return 0 in order to state that this
versions supports SKF_AD_PROTOCOL up to SKF_AD_PAY_OFFSET. Later
additions to BPF extensions need to add their bits to the
bpf_tell_extensions() function, as documented in the comment.

Signed-off-by: Michal Sekletar 
Cc: David Miller 
Reviewed-by: Daniel Borkmann 
Signed-off-by: David S. Miller

net: introduce SO_MAX_PACING_RATE

2013-09-28T22:35:41+00:00

As mentioned in commit afe4fd062416b ("pkt_sched: fq: Fair Queue packet
scheduler"), this patch adds a new socket option.

SO_MAX_PACING_RATE offers the application the ability to cap the
rate computed by transport layer. Value is in bytes per second.

u32 val = 1000000;
setsockopt(sockfd, SOL_SOCKET, SO_MAX_PACING_RATE, &val, sizeof(val));

To be effectively paced, a flow must use FQ packet scheduler.

Note that a packet scheduler takes into account the headers for its
computations. The effective payload rate depends on MSS and retransmits
if any.

I chose to make this pacing rate a SOL_SOCKET option instead of a
TCP one because this can be used by other protocols.

Signed-off-by: Eric Dumazet 
Cc: Steinar H. Gunderson 
Cc: Michael Kerrisk 
Signed-off-by: David S. Miller