On Fri, Jan 18, 2019 at 09:53:22AM +0530, Srinath Mannam wrote:
> In the current implementation, config read of 0x0001 data
> is assumed as CRS completion. but sometimes 0x0001 can be
> a valid data.
> IPROC PCIe RC has a register to show config request status flags
> like SC, UR, CRS and C
Em Fri, Jan 18, 2019 at 03:52:37PM +0100, Peter Zijlstra escreveu:
> On Fri, Jan 11, 2019 at 12:55:38PM -0300, Arnaldo Carvalho de Melo wrote:
> > Hi Peter,
> >
> > bpf_perf_event_open() already returns a value, but if
> > perf_event_output's output_begin (mostly perf_output_begin) fails,
> >
On Fri, 18 Jan 2019 at 13:09, Jan Kiszka wrote:
>
> On 17.01.19 10:54, Ulf Hansson wrote:
> > On Wed, 16 Jan 2019 at 21:26, Jan Kiszka wrote:
> >>
> >> On 16.01.19 12:37, Ulf Hansson wrote:
> >>> During "wlan-up", we are programming the FW into the WiFi-chip. However,
> >>> re-programming the FW
On Thu, 17 Jan 2019, Andrea Parri wrote:
> > Can the compiler (maybe, it does?) transform, at the C or at the "asm"
> > level, LB1's P0 in LB2's P0 (LB1 and LB2 are reported below)?
> >
> > C LB1
> >
> > {
> > int *x = &a;
> > }
> >
> > P0(int **x, int *y)
> > {
> > int *r0;
> >
> >
On Thu, Jan 17, 2019 at 08:59:00AM +0100, Roberto Sassu wrote:
> On 12/20/2018 4:21 PM, Jarkko Sakkinen wrote:
> > On Thu, Dec 13, 2018 at 11:29:45AM +0100, Roberto Sassu wrote:
> > > Currently, tpm_pcr_extend() accepts as an input only a SHA1 digest.
> > >
> > > This patch modifies the definition
The maximum value found in that array is 15, there's no need to store
these values as uint32_t, a uint8_t is enough.
Signed-off-by: Paul Cercueil
---
v2: Remove casts to uint32_t
drivers/memory/jz4780-nemc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/memory/jz4
Depending on MACH_JZ4780 prevent us from creating a generic kernel that
works on more than one MIPS board. Instead, we just depend on MIPS being
set.
Signed-off-by: Paul Cercueil
Reviewed-by: Boris Brezillon
---
v2: No change
drivers/memory/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 de
Add support for the JZ4725B SoC from Ingenic.
Signed-off-by: Paul Cercueil
Reviewed-by: Boris Brezillon
---
v2: No change
drivers/memory/jz4780-nemc.c | 24 +---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/memory/jz4780-nemc.c b/drivers/memory/jz
Add a compatible string to support the memory controller built into the
JZ4725B SoC from Ingenic.
Signed-off-by: Paul Cercueil
Reviewed-by: Boris Brezillon
---
v2: No change
.../devicetree/bindings/memory-controllers/ingenic,jz4780-nemc.txt | 1 +
1 file changed, 1 insertion(+)
diff --
Hi Sam,
Thank you for the patch.
On Sat, Jan 12, 2019 at 08:32:44PM +0100, Sam Ravnborg wrote:
> Move drm_can_sleep() out of drmP.h to allow users
> to get rid of the drmP.h include.
>
> There was no header file that was a good match for this helper function.
> So add this to drm_util with the r
Dear,i am lisa jaster,it would be great to know you,i have a very
important and confidential matter that i want to discuss with
you,reply me back for more discus.
Regards,
Lisa Jaster.
On Thu, Jan 17, 2019 at 09:32:55AM +0800, Jia Zhang wrote:
>
>
> On 2019/1/17 上午6:09, Jarkko Sakkinen wrote:
> > Please use "tpm:" tag for commits, not "tpm/eventlog/tpm1".
> >
> > On Fri, Jan 11, 2019 at 04:59:32PM +0800, Jia Zhang wrote:
> >> The responsibility of tpm1_bios_measurements_start(
Hi Hugo,
On Thu, Jan 17, 2019 at 11:41:35PM +0100, Hugo Lefeuvre wrote:
> introduce wait_event_freezable_hrtimeout, an interruptible and freezable
> version of wait_event_hrtimeout.
>
> simplify handle_vsoc_cond_wait (drivers/staging/android/vsoc.c) using this
> newly added helper and remove usel
On 1/17/19 11:47 PM, Yanmin Zhang wrote:
> a chance for kernel to allocate PMEM as DMA buffer.
> Some super speed devices like 10Giga NIC, USB (SSIC connecting modem),
> might not work well if DMA buffer is in PMEM as it's slower than DRAM.
>
> Should your patchset consider it?
No, I don't think
Hi Sam,
Thank you for the patch.
On Sat, Jan 12, 2019 at 08:32:45PM +0100, Sam Ravnborg wrote:
> In the quest to get rid of drmP.h move the newly
> added EXPORT_SYMBOL_FOR_TESTS_ONLY to drm_util.h.
Would it make sense to move it to drm_internal.h as it's really for
internal use of the DRM core ?
Register 1.21 "2.5G/5G PMA Extended abilities" contains the information
indicating whether or not 2.5GBASET and 5GBASET are supported by a PHY,
as per the 802.3bz specification.
If the bit 14 is set in the 1.11 "PMA Extended abilities" register, the
modes specified in the above-mentionned 1.21 reg
The 802.3bz specification, based on previous by the NBASET alliance,
defines the 2.5GBaseT and 5GBaseT link modes for ethernet traffic on
cat5e, cat6 and cat7 cables.
These mode integrate with the already defined C45 MDIO PMA/PMD registers
set that added 10G support, by defining some previously re
This patch adds support for the 88x2110 PHY, which is similar to the
already supported 88x3310 PHY without the SFP interface.
It supports 10/100/1000BASET along with 2.5GBASET, 5GBASET and 10GBASET,
with the same interface modes that are used by the 3310.
This PHY don't have the same issue as the
Hi Sam,
Thank you for the patch.
On Sat, Jan 12, 2019 at 08:32:50PM +0100, Sam Ravnborg wrote:
> The use of drmP.h is discouraged and removal of it from
> drm_modeset_helper.h caused rcar-du to fail to build.
>
> This patch introduce the necessary fixes to prepare for the
> drmP.h removal from d
As per 802.3bz, if bit 14 of (1.11) "PMA Extended Abilities" indicates
whether or not we should read register (1.21) "2.52/5G PMA Extended
Abilities", which contains information on the support of 2.5GBASET and
5GBASET.
After testing on several variants of PHYS of this family, it appears
that bit 1
The Marvell Alaska family of PHYs supports 2.5GBaseT and 5GBaseT modes,
as defined in the 802.3bz specification.
When the link partner requests a 2.5GBASET link, the PHY will
reconfigure it's MII interface to 2500BASEX.
At 5G, the PHY will reconfigure it's interface to 5GBASE-R, but this
mode isn
Marvell 10G PHY driver has a generic way of initializing the supported
link modes by reading the PHY's C45 PMA abilities. This can be made
generic, since these registers are part of the 802.3 specifications.
This commit extracts the config_init link_mode initialization code from
marvell10g and use
Hi Sam,
Thank you for the patch.
On Sat, Jan 12, 2019 at 08:32:51PM +0100, Sam Ravnborg wrote:
> With the removal of drmP.h from drm_modeset_helper.h
> the drmP.h are no longer included by any include files
> in include/drm.
> The drmP.h file is thus only included explicit
> either in .c files or
The PPv2 controller is able to support 2.5G speeds, allowing to use
2.5GBASET in conjunction with PHYs that use 2500BASEX as their MII
interface when using this mode.
Signed-off-by: Maxime Chevallier
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 1 +
1 file changed, 1 insertion(+)
diff
Hello everyone,
This series introduces support for 2.5GBASET mode in Network PHYs, and
implements that support in some PHYs in the Marvell Alaska product
range, the PPv2 driver, and a new PHY from the Alaska family.
2.5GBASET and 5GBASET were originally defined by the NBASET alliance,
and are now
> This is going to be a mammoth task. The alternatives are to continue
> as things are, which is a mess that cannot be cleaned up by either of
> (mutually exclusive) hardware or software alone.
>
> Thoughts and feedback appreciated.
You need to be talking to the JIT developers not asking here I t
On Thu, Dec 20, 2018 at 01:14:46PM +0800, Peng Hao wrote:
> Return 0 for empty body register function normally.
>
> Signed-off-by: Peng Hao
> ---
> v4 --> v5 : resolve kbuild issue: handle all typo "drvier/driver"
> in funtion name.
>
> v3 --> v4 : use pcim* function instead of pci
* Faiz Abbas [190118 10:54]:
> Tony,
>
> On 16/01/19 9:17 PM, Tony Lindgren wrote:
> > * Thierry Reding [190116 13:28]:
> >> On Tue, Jan 15, 2019 at 05:28:36PM +0100, Thomas Petazzoni wrote:
> >>> The SDHCI core is know properly checking for the state of a WP GPIO,
> >>
> >> "know" -> "now"
> >>
Hi,
On 1/17/19 2:16 PM, Dean Wallace wrote:
On 17-01-19, Hans de Goede wrote:
Mogens, Dean, can you please try the SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH
driver, without reverting any patches, with the attached patch on top and
see if that helps?
Hi Hans. Just compiled 4.20.3 with your new
Hi,
On 1/17/19 8:30 PM, Mogens Jensen wrote:
‐‐‐ Original Message ‐‐‐
On Thursday, January 17, 2019 12:05 PM, Hans de Goede
wrote:
Hi,
On 17-01-19 10:12, Dean Wallace wrote:
Hi Hans, Mogens,
On 17-01-19, Mogens Jensen wrote:
Kernel is compiled with SND_SOC_INTEL_CHT_BSW_MAX98090
* Ulf Hansson [190118 15:09]:
> On Fri, 18 Jan 2019 at 13:09, Jan Kiszka wrote:
> > Yeah, I'm not claiming at all I know what I'm doing there, just that it
> > happens
> > to work.
>
> I see. Good to know, thanks!
This seems like some separate issue. I wonder if adding
another reset just befor
Anders Roxell writes:
> On Wed, 16 Jan 2019 at 16:43, Tony Lindgren wrote:
>>
>> * Ulf Hansson [190116 11:37]:
>> > During "wlan-up", we are programming the FW into the WiFi-chip. However,
>> > re-programming the FW doesn't work, unless a power cycle of the WiFi-chip
>> > is made in-between the
On 18/01/2019 15:34, Catalin Marinas wrote:
> On Fri, Jan 18, 2019 at 02:36:46PM +0100, Marc Gonzalez wrote:
>
>> Trying to diagnose a separate issue, I enabled a raft of debugging options,
>> including kmemleak. However, it looks like kmemleak itself is crashing?
>>
>> We seem to be crashing on t
On 18.01.2019 15:12, Lucas Stach wrote:
> Am Freitag, den 18.01.2019, 14:59 +0100 schrieb Stefan Agner:
>> Explicitly specify interrupt affinity to avoid HW perfevents
>> need to guess. This avoids the following error upon boot:
>> hw perfevents: no interrupt-affinity property for /pmu, guessing.
On Thu, Jan 17, 2019 at 10:02 AM Jagan Teki wrote:
>
> On Thu, Jan 17, 2019 at 12:48 AM Maxime Ripard
> wrote:
> >
> > On Sun, Jan 13, 2019 at 01:07:41AM +0530, Jagan Teki wrote:
> > > > > > > > Again, I cannot help you without the datasheet for the panels
> > > > > > > > you're
> > > > > > > >
On Mon, Jan 14, 2019 at 10:02:21AM +, Suzuki K Poulose wrote:
>
>
> On 09/01/2019 23:55, Jeremy Linton wrote:
> > As suggested on the list, https://lkml.org/lkml/2019/1/4/282, there are
> > a number of cases where its useful for a system to avoid exporting a
> > sysfs entry for a given vulner
Thx Brajeswar,
Reviewed-by: Guo Ren
Acked-by: Guo Ren
On Fri, Jan 18, 2019 at 03:21:52PM +0530, Brajeswar Ghosh wrote:
> Remove linux/kernel.h which is included more than once
>
> Signed-off-by: Brajeswar Ghosh
> ---
> arch/csky/mm/fault.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --g
Hi,
* Andreas Kemnade [190116 22:04]:
> Deny autoidle for hwmods with the OCPIF_SWSUP_IDLE flag,
> that makes hwmods working properly which cannot handle
> autoidle properly in lower power states.
Sorry if I'm still missing something :)
But doesn't this now block autoidle for all modules
with O
Commit-ID: 0237199186e7a4aa5310741f0a6498a20c820fd7
Gitweb: https://git.kernel.org/tip/0237199186e7a4aa5310741f0a6498a20c820fd7
Author: Jiaxun Yang
AuthorDate: Tue, 20 Nov 2018 11:00:18 +0800
Committer: Borislav Petkov
CommitDate: Fri, 18 Jan 2019 16:44:03 +0100
x86/CPU/AMD: Set the CP
* Kalle Valo [190118 15:37]:
> Anders Roxell writes:
>
> > On Wed, 16 Jan 2019 at 16:43, Tony Lindgren wrote:
> >>
> >> * Ulf Hansson [190116 11:37]:
> >> > During "wlan-up", we are programming the FW into the WiFi-chip. However,
> >> > re-programming the FW doesn't work, unless a power cycle
On Fri, Jan 18, 2019 at 01:20:20PM +0100, Gerd Hoffmann wrote:
> Signed-off-by: Gerd Hoffmann
We already do all reasonable overflow checks in drm_mode_create_dumb(). If
you don't trust them I think would be better time spent typing an igt to
test this than adding redundant check in all drivers.
Hi Kai-Heng,
On Mon, Jan 7, 2019 at 8:24 AM Kai-Heng Feng
wrote:
>
> While using Elan touchpads, the message floods:
> [ 136.138487] i2c_hid i2c-DELL08D6:00: i2c_hid_get_input: incomplete report
> (14/65535)
>
> Though the message flood is annoying, the device it self works without
> any issue.
On Thu, Jan 10, 2019 at 09:37:32AM -0800, Alexander Duyck wrote:
> On Thu, 2018-12-20 at 16:28 +0100, Greg Kroah-Hartman wrote:
> > On Wed, Dec 19, 2018 at 03:27:48PM +0100, Rafael J. Wysocki wrote:
> > > On Thu, Dec 13, 2018 at 1:45 AM Alexander Duyck
> > > wrote:
> > > >
> > > > Add an addition
On Fri, Jan 18, 2019 at 04:23:49PM +0100, Maxime Chevallier wrote:
> @@ -264,8 +265,10 @@ static int mv3310_config_init(struct phy_device *phydev)
> if (ret)
> return ret;
>
> - linkmode_and(phydev->advertising, phydev->advertising,
> - phydev->supported);
On Wed, Dec 12, 2018 at 04:44:58PM -0800, Alexander Duyck wrote:
> Add an additional bit flag to the device struct named "dead".
>
> This additional flag provides a guarantee that when a device_del is
> executed on a given interface an async worker will not attempt to attach
> the driver following
On Fri, Jan 18, 2019 at 10:34:59AM +0800, Wei Yang wrote:
> As the description of struct device_private says, it stores data which
> is private to driver core. And it already has similar fields like:
> knode_parent, knode_driver, knode_driver and knode_bus. This look it is
> more proper to put knod
This ixes an issue when setting the encoder framerate because of
missing precision. Now the frameinterval type is changed to
TYPE_CONTINUOUS and step = 1. Also the math is changed when
framerate property is called - the firmware side expects that
the framerate one is 1 << 16 units.
Signed-off-by:
On Fri, Jan 18, 2019 at 10:10:22AM -0500, Alan Stern wrote:
> On Thu, 17 Jan 2019, Andrea Parri wrote:
>
> > > Can the compiler (maybe, it does?) transform, at the C or at the "asm"
> > > level, LB1's P0 in LB2's P0 (LB1 and LB2 are reported below)?
> > >
> > > C LB1
> > >
> > > {
> > > int *x
Hello
On 1/17/19 6:02 PM, Pavel Machek wrote:
> Hi!
>
>
>>> I am willing to work with you on the HSV and adapting the LP50xx part to
>>> this framework.
>>> Or any RGB framework for that matter. I still don't agree with the kernel
>>> needing to declare colors
>>> maybe color capabilities bu
A common pattern found in header files is a function declaration dependent
on a CONFIG_ option being enabled, followed by an empty function for when
that option isn't enabled. This boilerplate code can often take up a lot
of space and impact code readability.
This series introduces a STUB_UNLESS m
Use the STUB_UNLESS macro to simplify function declaration.
Signed-off-by: Andrew Murray
---
include/linux/cpufreq.h | 21 ++---
1 file changed, 6 insertions(+), 15 deletions(-)
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index c86d6d8..2c53cae 100644
--- a/in
A common pattern found in header files is a function declaration dependent
on a CONFIG_ option being enabled, followed by an empty function for when
that option isn't enabled. This can often take up a lot of space and impact
code readability.
Let's introduce the following STUB_UNLESS macro:
STUB_
Use the STUB_UNLESS macro to simplify function declaration.
Signed-off-by: Andrew Murray
---
arch/arm64/include/asm/acpi.h | 38 +-
arch/arm64/include/asm/alternative.h| 6 +---
arch/arm64/include/asm/cpufeature.h | 6 +---
arch/arm64/include/asm/cpuidle.h
On Wed, Jan 9, 2019 at 7:08 PM Rob Herring wrote:
>
> Please CC DT list if you want bindings reviewed.
Sorry I forgot.
>
> On Wed, Jan 9, 2019 at 1:40 AM Dmitry Torokhov
> wrote:
> >
> > On Sat, Dec 15, 2018 at 08:47:59PM +0530, Jagan Teki wrote:
> > > Most of the Goodix CTP controllers are sup
On Wed, Jan 16, 2019 at 07:52:08PM +, Alakesh Haloi wrote:
> [ Upstream commit 512ac999d2755d2b7109e996a76b6fb8b888631d ]
>
> I noticed that cgroup task groups constantly get throttled even
> if they have low CPU usage, this causes some jitters on the response
> time to some of our business co
Hi Julien,
On Tue, Jan 08, 2019 at 02:07:30PM +, Julien Thierry wrote:
> + * Having two ways to control interrupt status is a bit complicated. Some
> + * locations like exception entries will have PSR.I bit set by the
> architecture
> + * while PMR is unmasked.
> + * We need the irqflags to r
On 1/18/19 3:59 AM, Greg Kroah-Hartman wrote:
> On Fri, Jan 11, 2019 at 12:05:21PM -0600, Andrew F. Davis wrote:
>> When enabled the helpers functions for creating carveout and chunk heaps
>> should have declarations in the ION header.
>
> Why? No one calls these from what I can tell.
>
> Which
On Fri, Jan 18, 2019 at 09:09:04AM -0500, Vince Weaver wrote:
> On Fri, 18 Jan 2019, Peter Zijlstra wrote:
>
> > On Fri, Jan 11, 2019 at 04:52:22PM -0500, Vince Weaver wrote:
> > > On Thu, 10 Jan 2019, Vince Weaver wrote:
> > >
> > > > On Thu, 10 Jan 2019, Vince Weaver wrote:
> > > >
> > > > > O
On Fri, Jan 18, 2019 at 10:42:05AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Jan 18, 2019 at 10:01:06AM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Fri, Jan 18, 2019 at 09:59:20AM -0300, Arnaldo Carvalho de Melo escreveu:
> > > Thanks, tested and applied.
>
> > > While testing I found
On Tue, Jan 08, 2019 at 02:07:26PM +, Julien Thierry wrote:
> In order to replace PSR.I interrupt disabling/enabling with ICC_PMR_EL1
> interrupt masking, ICC_PMR_EL1 needs to be saved/restored when
> taking/returning from an exception. This mimics the way hardware saves
> and restores PSR.I bi
On Fri, Jan 18, 2019 at 02:27:25PM +0200, Elena Reshetova wrote:
> Elena Reshetova (5):
> sched: convert sighand_struct.count to refcount_t
> sched: convert signal_struct.sigcnt to refcount_t
These should really be seen by Oleg (bounced) and I'll await his reply.
> sched: convert numa_group
On Fri, Jan 18, 2019 at 10:19:41AM -0500, Joel Fernandes wrote:
> You should document the variable names in the header comments.
>
> Also, this new API appears to conflict with definition of 'freezable' in
> wait_event_freezable I think,
>
> wait_event_freezable - sleep or freeze until condition
> +static bool perf_evsel__should_skip(struct perf_evsel *evsel)
> +{
> + struct perf_event_attr *attr = &evsel->attr;
> + struct perf_evsel *leader = evsel->leader;
> +
> + return (leader != evsel) && !attr->freq && !attr->sample_freq;
> +}
> +
> static int process_sample_event(struct
On 1/18/19 10:36 AM, Marc Gonzalez wrote:
> On 18/01/2019 15:34, Catalin Marinas wrote:
>
>> On Fri, Jan 18, 2019 at 02:36:46PM +0100, Marc Gonzalez wrote:
>>
>>> Trying to diagnose a separate issue, I enabled a raft of debugging options,
>>> including kmemleak. However, it looks like kmemleak
Multiple filesystems can already return EFSCORRUPTED errors to userspace;
however, so far, definitions of EFSCORRUPTED were in filesystem-private
headers.
I wanted to use EUCLEAN to indicate data corruption in the VFS layer;
Dave Chinner says that I should instead hoist the definitions of
EFSCORRU
As Al Viro pointed out, many filldir_t functions return error codes, but
all callers of filldir_t functions just check whether the return value is
non-zero (to determine whether to continue reading the directory); more
precise errors have to be signalled via struct dir_context.
Change all filldir_t
When you e.g. run `find` on a directory for which getdents returns
"filenames" that contain slashes, `find` passes those "filenames" back to
the kernel, which then interprets them as paths. That could conceivably
cause userspace to do something bad when accessing something like an
untrusted USB sti
On Thu, Jan 10, 2019 at 11:02:05AM +0800, Chunyan Zhang wrote:
> From: Vincent Wang
>
> When a task that is in_iowait state is enqueued, cpufreq_update_util()
> will be invoked with SCHED_CPUFREQ_IOWAIT flag. In this case,the value
> of util and cap, which are parameters used in map_util_freq(),
On Thu, Jan 17, 2019 at 08:14:15PM +0200, Leon Romanovsky wrote:
> From: Parav Pandit
>
> RDMA cgroup registration routine always returns success,
> so simplify function to be void and run clang formatter
> over whole CONFIG_CGROUP_RDMA art of core_priv.h.
>
> This reduces unwinding error path f
On Thu, Jan 17, 2019 at 09:47:34AM +0100, Juri Lelli wrote:
> Hi,
>
> v6 of a series of patches, originally authored by Mathieu, with the intent
> of fixing a long standing issue of SCHED_DEADLINE bandwidth accounting.
> As originally reported by Steve [1], when hotplug and/or (certain)
> cpuset r
On Fri, Jan 18, 2019 at 08:11:42AM -0800, Andi Kleen wrote:
> > +static bool perf_evsel__should_skip(struct perf_evsel *evsel)
> > +{
> > + struct perf_event_attr *attr = &evsel->attr;
> > + struct perf_evsel *leader = evsel->leader;
> > +
> > + return (leader != evsel) && !attr->freq && !att
Want to shoot photos for your products and retouching also i needed?
We are studio special for photo shooting and retouching.
For your photos:
White background, Optimized for Shopify, Retouching included
Revisions accepted
We can also give you dedicate editing service for your photos
Let me kn
As Joseph Myers points out, alpha has never had a standard statfs64
interface and instead returns only 32-bit numbers here.
While there is an old osf_statfs64 system call that returns additional
data, this has some other quirks and does not get used in glibc.
I considered making the stat64 struct
Alpha has traditionally followed the OSF1 calling conventions
here, with its getxpid, getxuid, getxgid system calls returning
two different values in separate registers.
Following what glibc has done here, we can define getpid,
getuid and getgid to be aliases for getxpid, getxuid and getxgid
respe
On Fri, Jan 18, 2019 at 12:09:38PM -0300, Arnaldo Carvalho de Melo wrote:
> commit 1b3b3dee572d0b77a316ab6715091201be6832de
> Author: Arnaldo Carvalho de Melo
> Date: Fri Jan 11 13:20:20 2019 -0300
>
> perf: Make perf_event_output() propagate the output() return
>
> For the origina
__kernel_timespec and timespec are currently the same type, but once
they are different, the type cast has to be changed here.
Signed-off-by: Arnd Bergmann
---
arch/sparc/kernel/sys_sparc_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/sparc/kernel/sys_sparc_64.c b/
Most architectures have assigned a numbers for the seccomp syscall
even when they do not implement it.
m68k is an exception here, so for consistency lets add the number.
Unless CONFIG_SECCOMP is implemented, the system call just
returns -ENOSYS.
Signed-off-by: Arnd Bergmann
---
arch/m68k/kernel
All architectures should implement these two, so assign numbers
and hook them up on ia64.
Signed-off-by: Arnd Bergmann
---
arch/ia64/kernel/syscalls/syscall.tbl | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/ia64/kernel/syscalls/syscall.tbl
b/arch/ia64/kernel/syscalls/syscall.tbl
in
When I merged this patch, the file was accidentally left intact
instead of being removed, which means any changes to syscall.tbl
have no effect.
Fixes: 2b3c5a99d5f3 ("sh: generate uapi header and syscall table header files")
Signed-off-by: Arnd Bergmann
---
arch/sh/include/uapi/asm/unistd_32.h |
The behavior of these system calls is slightly different between
architectures, as determined by the CONFIG_ARCH_WANT_IPC_PARSE_VERSION
symbol. Most architectures that implement the split IPC syscalls don't set
that symbol and only get the modern version, but alpha, arm, microblaze,
mips-n32, mips-
This is a minor update of the patches I posted last week, I
would like to add this into linux-next now, but would still do
changes if there are concerns about the contents. The first
version did not see a lot of replies, which could mean that
either everyone is happy with it, or that it was largely
x32 has always followed the time64 calling conventions of these
syscalls, which required a special hack in compat_get_timespec
aka get_old_timespec32 to continue working.
Since we now have the time64 syscalls, use those explicitly.
Signed-off-by: Arnd Bergmann
---
arch/x86/entry/syscalls/syscal
Other architectures commonly use __NR_umount2 for sys_umount,
only ia64 and alpha use __NR_umount here. In order to synchronize
the generated tables, use umount2 like everyone else, and add back
the old name from asm/unistd.h for compatibility.
For shmat, alpha uses the osf_shmat name, we can do t
A small typo has crept into the y2038 conversion of the timer_settime
system call. So far this was completely harmless, but once we start
using the new version, this has to be fixed.
Fixes: 6ff847350702 ("time: Change types to new y2038 safe __kernel_itimerspec")
Signed-off-by: Arnd Bergmann
---
From: Deepa Dinamani
struct timex is not y2038 safe.
Replace all uses of timex with y2038 safe __kernel_timex.
Note that struct __kernel_timex is an ABI interface definition.
We could define a new structure based on __kernel_timex that
is only available internally instead. Right now, there isn't
We now use 64-bit time_t on all architectures, so the __kernel_timex,
__kernel_timeval and __kernel_timespec redirects can be removed
after having served their purpose.
This makes it all much less confusing, as the __kernel_* types
now always refer to the same layout based on 64-bit time_t across
This is the big flip, where all 32-bit architectures set COMPAT_32BIT_TIME
abd use the _time32 system calls from the former compat layer instead
of the system calls that take __kernel_timespec and similar arguments.
The temporary redirects for __kernel_timespec, __kernel_itimerspec
and __kernel_ti
These are all for ignoring the lack of obsolete system calls,
which have been marked the same way in scripts/checksyscall.sh,
so these can be removed.
Signed-off-by: Arnd Bergmann
---
arch/mips/include/asm/unistd.h | 16
arch/parisc/include/asm/unistd.h | 3 ---
arch/s390/inc
We want to reuse the compat_timex handling on 32-bit architectures the
same way we are using the compat handling for timespec when moving to
64-bit time_t.
Move all definitions related to compat_timex out of the compat code
into the normal timekeeping code, along with a rename to old_timex32,
corr
From: Deepa Dinamani
struct timex uses struct timeval internally.
struct timeval is not y2038 safe.
Introduce a new UAPI type struct __kernel_timex
that is y2038 safe.
struct __kernel_timex uses a timeval type that is
similar to struct __kernel_timespec which preserves the
same structure size ac
On Tue, Jan 15, 2019 at 1:01 AM Dave Chinner wrote:
> On Mon, Jan 14, 2019 at 07:23:17PM +0100, Jann Horn wrote:
> > When you e.g. run `find` on a directory for which getdents returns
> > "filenames" that contain slashes, `find` passes those "filenames" back to
> > the kernel, which then interpret
On Tue, Jan 08, 2019 at 02:07:27PM +, Julien Thierry wrote:
> CPU does not received signals for interrupts with a priority masked by
> ICC_PMR_EL1. This means the CPU might not come back from a WFI
> instruction.
>
> Make sure ICC_PMR_EL1 does not mask interrupts when doing a WFI.
>
> Since t
From: Rui Zhao
New driver supports DRAM error detection and correction on DMC520
controller.
Validated on actual hardware: DRAM errors showed up once the DDR core
voltage was lowered down by 200+mV using test tool.
Signed-off-by: Rui Zhao
[sl: minor nits in commit message and code, added maint
Most architectures define system call numbers for the rseq and pkey system
calls, even when they don't support the features, and perhaps never will.
Only a few architectures are missing these, so just define them anyway
for consistency. If we decide to add them later to one of these, the
system ca
On Fri, Jan 18, 2019 at 5:15 PM Jann Horn wrote:
>
> Multiple filesystems can already return EFSCORRUPTED errors to userspace;
> however, so far, definitions of EFSCORRUPTED were in filesystem-private
> headers.
>
> I wanted to use EUCLEAN to indicate data corruption in the VFS layer;
> Dave Chinn
The IPC system call handling is highly inconsistent across architectures,
some use sys_ipc, some use separate calls, and some use both. We also
have some architectures that require passing IPC_64 in the flags, and
others that set it implicitly.
For the additon of a y2083 safe semtimedop() system
A lot of system calls that pass a time_t somewhere have an implementation
using a COMPAT_SYSCALL_DEFINEx() on 64-bit architectures, and have
been reworked so that this implementation can now be used on 32-bit
architectures as well.
The missing step is to redefine them using the regular SYSCALL_DEF
Hi Alex,
If you have time please review this patch, I'd like to send a pull
request for this series.
On 1/9/19 10:46 AM, Stanimir Varbanov wrote:
> By historical reasons we defined firmware memory size to be 6MB even
> that the firmware size for all supported Venus versions is 5MBs. Correct
> tha
Other architectures commonly use __NR_umount2 for sys_umount,
only ia64 and alpha use __NR_umount here. In order to synchronize
the generated tables, use umount2 like everyone else, and add back
the old name from asm/unistd.h for compatibility.
The __IGNORE_* lines are now all obsolete and can be
A couple of architectures including arm64 already implement the
kexec_file_load system call, on many others we have assigned a system
call number for it, but not implemented it yet.
Adding the number in arch/arm/ lets us use the system call on arm64
systems in compat mode, and also reduces the num
501 - 600 of 1016 matches
Mail list logo
