The count_read and count_write callbacks pass unsigned long now, while
the signal_read callback passes an enum counter_signal_value.
Signed-off-by: William Breathitt Gray
---
drivers/counter/104-quad-8.c | 33 ++---
1 file changed, 10 insertions(+), 23 deletions(-)
The count_read and count_write callbacks are simplified to pass val as
unsigned long rather than as an opaque data structure. The opaque
counter_count_read_value and counter_count_write_value structures,
counter_count_value_type enum, and relevant counter_count_read_value_set
and
Count data is now always represented as an unsigned integer, while
Signal data is either SIGNAL_LOW or SIGNAL_HIGH.
Signed-off-by: William Breathitt Gray
---
Documentation/driver-api/generic-counter.rst | 22 +++-
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git
The signal_read callback is simplified to pass val as a
counter_signal_val enum rather than as an opaque data structure. The
opaque counter_signal_read_value structure and relevant
counter_signal_read_value_set function are removed as they are no longer
used. In addition, the counter_signal_level
I have a simplification for the the Counter subsystem callbacks, but I
want to get some comments first before committing further. Since this is
an RFC, I've included updates to the 104-QUAD-8 driver here for the
sake of demonstration; if the comments received are positive, I'll
submit the changes
getrandom() has been created as a new and more secure interface for
pseudorandom data requests. Unlike /dev/urandom, it unconditionally
blocks until the entropy pool has been properly initialized.
While getrandom() has no guaranteed upper bound for its waiting time,
user-space has been abusing
On Thu, Sep 12, 2019 at 08:31:27PM +0800, Cao jin wrote:
> fix typos for:
> elaboarte -> elaborate
> architecure -> architecture
> compltes -> completes
>
> And, convert the markup :c:func:`foo` to foo() as kernel documentation
> toolchain can recognize foo() as a function.
>
>
Hi, RMS and Bruce Perens;
I noticed that recently Grsecurity's Brad Spengler (who sued you, Bruce,
for speaking the truth), decided to "Flex" and basically advertise while
chastising the linux community:
news.ycombinator.com/item?id=20874470
Another poster then pointed out the history of
If the return value of vhci_init_attr_group and
sysfs_create_group is non-zero, which mean they failed
to init attr_group and create sysfs group, so it would
better add 'failed' message to indicate that.
Fixes: 0775a9cbc694 ("usbip: vhci extension: modifications to vhci driver")
Signed-off-by:
From:
reason: migration to invalid cpu in __set_cpus_allowed_ptr
archive path: patches/euleros/sched
Oops occur when running qemu on arm64:
Unable to handle kernel paging request at virtual address 08effe40
Internal error: Oops: 9607 [#1] SMP
Process migration/0 (pid: 12, stack
On 3/9/19 7:45 pm, Anshuman Khandual wrote:
> The arm64 page table dump code can race with concurrent modification of the
> kernel page tables. When a leaf entries are modified concurrently, the dump
> code may log stale or inconsistent information for a VA range, but this is
> otherwise not
Kernel is 5.3-rc8 on x86_64.
Loading, unloading, and then loading the vimc-debayer module causes:
[ 793.542496] [ cut here ]
[ 793.542518] DEBUG_LOCKS_WARN_ON(lock->magic != lock)
[ 793.542536] WARNING: CPU: 3 PID: 2029 at ../kernel/locking/mutex.c:912
Hi Qian,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3-rc8 next-20190904]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
On Sat, Sep 14, 2019 at 7:05 PM Theodore Y. Ts'o wrote:
>
> I'd be willing to let it take at least 2 minutes, since that's slow
> enough to be annoying.
Have you ever met a real human being?
A boot that blocks will result in people pressing the big red button
in less than 30 seconds, unless it
On Sat, Sep 14, 2019 at 06:10:47PM -0700, Linus Torvalds wrote:
> > We could return 0 for success, and yet "the best we
> > can do" could be really terrible.
>
> Yes. Which is why we should warn.
I'm all in favor of warning. But people might just ignore the
warning. We warn today about systemd
On 15-Sep 00:33, Yonghong Song wrote:
>
>
> On 9/10/19 12:55 PM, KP Singh wrote:
> > From: KP Singh
> >
> > Adds a callback which is called when a new program is attached
> > to a hook. The callback registered by the process_exection hook
> > checks if a program that has calls to a helper that
On Sat, Sep 14, 2019 at 6:00 PM Theodore Y. Ts'o wrote:
>
> That makes me even more worried. It's probably going to be OK for
> modern x86 systems, since "best we can do" will include RDRAND
> (whether or not it's trusted). But on systems without something like
> RDRAND --- e.g., ARM --- the
>
> >
> > {disable,enable}_si_irq() themselves are racy:
> >
> > static inline bool disable_si_irq(struct smi_info *smi_info)
> > {
> > if ((smi_info->io.irq) && (!smi_info->interrupt_disabled)) {
> > smi_info->interrupt_disabled = true;
> >
> > Basically
On Sat, Sep 14, 2019 at 03:32:46PM -0700, Linus Torvalds wrote:
> > Worse, it won't even accomplish something against an obstinant
> > programmers. Someone who is going to change their program to sleep
> > loop waiting for getrandom(2) to not return with an error can just as
> > easily check for
Hi Greg,
On 9/14/19 1:31 AM, Greg Kroah-Hartman wrote:
On Sat, Sep 14, 2019 at 01:28:39AM -0700, Guenter Roeck wrote:
On 9/13/19 6:06 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.9.193 release.
There are 14 patches in this series, all will be posted as
On 9/14/19 5:56 PM, Yonghong Song wrote:
>
>
> On 9/10/19 12:55 PM, KP Singh wrote:
>> From: KP Singh
>>
>> A user space program can attach an eBPF program by:
>>
>> hook_fd = open("/sys/kernel/security/krsi/process_execution", O_RDWR)
>> prog_fd = bpf(BPF_PROG_LOAD, ...)
>>
On 9/10/19 12:55 PM, KP Singh wrote:
> From: KP Singh
>
> Adds a callback which is called when a new program is attached
> to a hook. The callback registered by the process_exection hook
> checks if a program that has calls to a helper that requires pages to
> be pinned (eg. krsi_get_env_var).
On 9/10/19 12:55 PM, KP Singh wrote:
> From: KP Singh
>
> * The program takes the name of an environment variable as an
> argument.
> * An eBPF program is loaded and attached to the
> process_execution hook.
> * The name of the environment variable passed
On 9/10/19 12:55 PM, KP Singh wrote:
> From: KP Singh
This patch cannot apply cleanly.
-bash-4.4$ git apply ~/p12.txt
error: patch failed: include/uapi/linux/bpf.h:2715
error: include/uapi/linux/bpf.h: patch does not apply
error: patch failed: tools/include/uapi/linux/bpf.h:2715
error:
On Fri, 13 Sep 2019 15:28:26 +0300
Andy Shevchenko wrote:
> On Tue, Aug 06, 2019 at 11:33:52AM -0400, Steven Rostedt wrote:
> > On Tue, 6 Aug 2019 18:15:43 +0300
> > Andy Shevchenko wrote:
> >
> > > Hex dump as many as 16 bytes at once in trace_print_hex_seq()
> > > instead of byte-by-byte
Hello,
Okash Khawaja, le sam. 14 sept. 2019 22:08:35 +0100, a ecrit:
> 2. We are still missing descriptions for i18n/ directory. I have added
> filenames below. can someone can add description please:
There are some descriptions in the "14.1. Files Under the i18n
Subdirectory" section of
The pull request you sent on Fri, 13 Sep 2019 13:57:24 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git tags/mmc-v5.3-rc8
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/1c4c5e2528af0c803fb1171632074f4070229a75
Thank you!
--
Deet-doot-dot, I am a
The pull request you sent on Sat, 14 Sep 2019 06:52:48 -0700 (PDT):
> git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git
> tags/riscv/for-v5.3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b03c036e6f96340dd311817c7b964dad183c4141
Thank you!
--
The pull request you sent on Sat, 14 Sep 2019 22:31:41 +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/1609d7604b847a9820e63393d1a3b6cac7286d40
Thank you!
--
Deet-doot-dot, I am a bot.
The pull request you sent on Sat, 14 Sep 2019 15:38:59 -0400:
> https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/1f9c632cde0c3d781463a88ce430a8dd4a7c1a0e
Thank you!
--
Deet-doot-dot, I am a
The pull request you sent on Fri, 13 Sep 2019 21:55:40 +0100 (WEST):
> git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git refs/heads/master
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/36024fcf8d28999f270908e75675d43b099ff7b3
Thank you!
--
On Sat, Sep 14, 2019 at 3:24 PM Theodore Y. Ts'o wrote:
>
> > > Also, we might even want to just fill the buffer and return 0 at that
> > > point, to make sure that even more broken user space doesn't then try
> > > to sleep manually and turn it into a "I'll wait myself" loop.
>
> Ugh. This
On Sat, Sep 14, 2019 at 11:11:26PM +0200, Ahmed S. Darwish wrote:
> > > I've sent an RFC patch at [1].
> > >
> > > [1] https://lkml.kernel.org/r/20190914122500.GA1425@darwi-home-pc
> >
> > Looks reasonable to me. Except I'd just make it simpler and make it a
> > big WARN_ON_ONCE(), which is a lot
Ahmed S. Darwish - 14.09.19, 23:11:26 CEST:
> > Yeah, the above is yet another example of completely broken garbage.
> >
> > You can't just wait and block at boot. That is simply 100%
> > unacceptable, and always has been, exactly because that may
> > potentially mean waiting forever since you
Move ATS function prototypes from include/linux/pci.h
to include/linux/pci-ats.h as the ATS, PRI, and PASID
interfaces are related, and are used only by the IOMMU
drivers. This effecively reverts the change done in
commit ff9bee895c4d ("PCI: Move ATS declarations to
linux/pci.h so they're all
Hi,
On Sat, Sep 14, 2019 at 09:30:19AM -0700, Linus Torvalds wrote:
> On Sat, Sep 14, 2019 at 8:02 AM Ahmed S. Darwish wrote:
> >
> > On Thu, Sep 12, 2019 at 12:34:45PM +0100, Linus Torvalds wrote:
> > >
> > > An alternative might be to make getrandom() just return an error
> > > instead of
On Mon, Sep 9, 2019 at 3:55 AM Gregory Nowak wrote:
>
> On Sun, Sep 08, 2019 at 10:43:02AM +0100, Okash Khawaja wrote:
> > Sorry, I have only now got round to working on this. It's not complete
> > yet but I have assimilated the feedback and converted subjective
> > phrases, like "I think..."
Linus,
The following changes since commit a7f89616b7376495424f682b6086e0c391a89a1d:
Merge branch 'for-5.3-fixes' of
git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup (2019-09-13 09:52:01
+0100)
are available in the git repository at:
https://git.kernel.org/pub/scm/virt/kvm/kvm.git
On Sat, Sep 14, 2019 at 06:18:03PM +0300, Ivan Safonov wrote:
> On 9/10/19 2:59 PM, Dan Carpenter wrote:
> > On Sun, Sep 08, 2019 at 12:00:26PM +0300, Ivan Safonov wrote >> rtw_malloc
> > prevents the use of kmemdup/kzalloc and others.
> > >
> > > Signed-off-by: Ivan Safonov
> > > ---
> > >
On Sat, 14 Sep 2019 12:42:32 PDT (-0700), charles.papon...@gmail.com wrote:
I had issues with that plic driver. The current implementation wasn't
usable with driver using level sensitive interrupt together with the
IRQF_ONESHOT flag.
Those null were producing crashes in the chained_irq_enter
On Sat, Sep 14, 2019 at 10:22 PM Srinivas Pandruvada
wrote:
>
> On Sat, 2019-09-14 at 20:19 +0300, Andy Shevchenko wrote:
> > On Sat, Sep 14, 2019 at 12:05:08AM -0700, Srinivas Pandruvada wrote:
> > > This series contains some minor fixes, when firmware mask is
> > > including
> > > invalid CPU
Using enable core mask, do online offline CPUs. There is a new option
--online|-o for set-config-level.
Signed-off-by: Srinivas Pandruvada
---
.../x86/intel-speed-select/isst-config.c | 60 +--
tools/power/x86/intel-speed-select/isst.h | 2 +
2 files changed, 58
From: Youquan Song
If the CPU package has the less logical CPU than topo_max_cpus, but un-present
CPU's punit_cpu_core will be initiated to 0 and they will be count to core 0
Like below, there are only 10 high priority cores (20 logical CPUs) in the CPU
package, but it count to 27 logic CPUs.
Fix wrong debug print for cpu, which is displayed as CLOS. Also
avoid printing clos id, when user is specify clos as parameter.
Signed-off-by: Srinivas Pandruvada
---
tools/power/x86/intel-speed-select/isst-config.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
This series contains some minor fixes, when firmware mask is including
invalid CPU in the perf-profile mask. Also add some commands to
better manage core-power feature.
v2:
Add exit(0) for invalid argument when -c/--cpu not specified for new
clos commands.
Fix online/offline based on TDP change
Format the get-assoc command output consistant with other commands.
For example:
Intel(R) Speed Select Technology
Executing on CPU model:142[0x8e]
package-0
die-0
cpu-0
get-assoc
clos:0
Signed-off-by: Srinivas Pandruvada
---
.../x86/intel-speed-select/isst-config.c |
Add additional command to get the clos enable and priority type. The
current info option is actually dumping per clos QOS config, so name
the command appropriately to get-config.
Signed-off-by: Srinivas Pandruvada
---
.../x86/intel-speed-select/isst-config.c | 38 ++-
I had issues with that plic driver. The current implementation wasn't
usable with driver using level sensitive interrupt together with the
IRQF_ONESHOT flag.
Those null were producing crashes in the chained_irq_enter function.
Filling them with dummy function fixed the issue.
On Sat, Sep 14,
So I made a mess of it. Sent a pull before making sure it works on 32
bit too. Hope it's not too late to revert. Will teach me to be way more
careful in the near future.
The following changes since commit 060423bfdee3f8bc6e2c1bac97de24d5415e2bc4:
vhost: make sure log_num < in_num (2019-09-11
On Sat, Sep 14, 2019 at 01:44:57AM -0700, Guenter Roeck wrote:
> Building vhost on 32-bit targets results in the following error.
>
> drivers/vhost/vhost.c: In function 'translate_desc':
> include/linux/compiler.h:549:38: error:
> call to '__compiletime_assert_1879' declared with attribute
On Thu, Sep 05, 2019 at 04:13:04PM +0200, Alexandre Belloni wrote:
>
> Implement .get_multiple and .set_multiple to allow reading or setting
> multiple pins simultaneously. Pins in the same bank will all be switched at
> the same time, improving synchronization and performances.
>
>
On Wed, Sep 11, 2019 at 10:24:14AM +0200, Eugen Hristev - M18282 wrote:
> From: Eugen Hristev
>
> Hello,
>
> This series adds support for analog and digital filters for i2c controllers
>
> This series is based on the series:
> [PATCH v2 0/9] i2c: at91: filters support for at91 SoCs
> and later
On Sat, 14 Sep 2019 06:05:59 PDT (-0700), Anup Patel wrote:
-Original Message-
From: linux-kernel-ow...@vger.kernel.org On Behalf Of Palmer Dabbelt
Sent: Saturday, September 14, 2019 6:30 PM
To: m...@aurabindo.in
Cc: Troy Benjegerdes ; Paul Walmsley
; a...@eecs.berkeley.edu; linux-
On Sat, 2019-09-14 at 20:19 +0300, Andy Shevchenko wrote:
> On Sat, Sep 14, 2019 at 12:05:08AM -0700, Srinivas Pandruvada wrote:
> > This series contains some minor fixes, when firmware mask is
> > including
> > invalid CPU in the perf-profile mask. Also add some commands to
> > better manage
On Sat, Sep 14, 2019 at 10:09 AM Alexander E. Patrakov
wrote:
>
> > Which means that we're all kinds of screwed. The whole "we guarantee
> > entropy" model is broken.
>
> I agree here. Given that you suggested "to just fill the buffer and
> return 0" in the previous mail (well, I think you really
On Wed, Sep 11, 2019 at 12:58:54PM +0300, Codrin Ciubotariu wrote:
> After a transfer timeout, some faulty I2C slave devices might hold down
> the SCL or the SDA pins. We can generate a bus clear command, hoping that
> the slave might release the pins.
>
> Signed-off-by: Codrin Ciubotariu
On Thu, 12 Sep 2019 14:40:34 PDT (-0700), Darius Rad wrote:
As per the existing comment, irq_mask and irq_unmask do not need
to do anything for the PLIC. However, the functions must exist
(the pointers cannot be NULL) as they are not optional, based on
the documentation
On 9/10/19 12:55 PM, KP Singh wrote:
> From: KP Singh
>
> This helper is mapped to the existing operation
> BPF_FUNC_perf_event_output.
>
> An example usage of this function would be:
>
> #define BUF_SIZE 64;
>
> struct bpf_map_def SEC("maps") perf_map = {
> .type =
On Sat, Sep 14, 2019 at 5:30 AM Eric W. Biederman wrote:
>
> I have reworked these patches one more time to make it clear that the
> first 3 patches only fix task_struct so that it experiences a rcu grace
> period after it leaves the runqueue for the last time.
I remain a fan of these patches,
Hi Christian,
my nit-picks below
On Fri, Sep 6, 2019 at 4:34 PM Christian Hewitt
wrote:
[...]
> + spdif_dit: audio-codec-1 {
> + #sound-dai-cells = <0>;
> + compatible = "linux,spdif-dit";
> + status = "okay";
> + sound-name-prefix =
Hi Jianxin,
On Thu, Sep 12, 2019 at 10:20 AM Jianxin Pan wrote:
>
> A1 is an application processor designed for smart audio and IoT applications,
> with Dual core ARM Cortex-A35 CPU. Unlike the previous GXL and G12 series,
> there is no Cortex-M3 AO CPU in it.
it will be interesting to see which
From: Ivan Lazeev
Bug link: https://bugzilla.kernel.org/show_bug.cgi?id=195657
cmd/rsp buffers are expected to be in the same ACPI region.
For Zen+ CPUs BIOS's might report two different regions, some of
them also report region sizes inconsistent with values from TPM
registers.
Memory
On Sat, Sep 14, 2019 at 12:05:08AM -0700, Srinivas Pandruvada wrote:
> This series contains some minor fixes, when firmware mask is including
> invalid CPU in the perf-profile mask. Also add some commands to
> better manage core-power feature.
Hmm... 150+ LOCs doesn't count to me as minor fixes.
14.09.2019 21:52, Linus Torvalds пишет:
On Sat, Sep 14, 2019 at 9:35 AM Alexander E. Patrakov
wrote:
Let me repeat: not -EINVAL, please. Please find some other error code,
so that the application could sensibly distinguish between this case
(low quality entropy is in the buffer) and the
On Fri, Sep 13, 2019 at 03:55:47PM -0700, Dmitry Torokhov wrote:
> The MDIO device reset line is optional and now that gpiod_get_optional()
> returns proper value when GPIO support is compiled out, there is no
> reason to use fwnode_get_named_gpiod() that I plan to hide away.
>
> Let's switch to
On 9/10/19 12:55 PM, KP Singh wrote:
> From: KP Singh
>
> A user space program can attach an eBPF program by:
>
>hook_fd = open("/sys/kernel/security/krsi/process_execution", O_RDWR)
>prog_fd = bpf(BPF_PROG_LOAD, ...)
>bpf(BPF_PROG_ATTACH, hook_fd, prog_fd)
>
> When such an
Hi Giovanni
On Monday 09 Sep 2019 at 04:42:15 (+0200), Giovanni Gherdovich wrote:
> +static inline long arch_scale_freq_capacity(int cpu)
> +{
> + if (static_cpu_has(X86_FEATURE_APERFMPERF))
> + return per_cpu(arch_cpu_freq, cpu);
So, if this is conditional, perhaps you could
On Sat, Sep 14, 2019 at 9:35 AM Alexander E. Patrakov
wrote:
>
> Let me repeat: not -EINVAL, please. Please find some other error code,
> so that the application could sensibly distinguish between this case
> (low quality entropy is in the buffer) and the "kernel is too dumb" case
> (and no
Le 14/09/2019 à 16:34, Scott Wood a écrit :
On Fri, 2019-08-23 at 12:50 +, Christophe Leroy wrote:
On mpc83xx with a QE, IMMR is 2Mbytes.
On mpc83xx without a QE, IMMR is 1Mbytes.
Each driver will map a part of it to access the registers it needs.
Some driver will map the same part of
14.09.2019 21:30, Linus Torvalds пишет:
On Sat, Sep 14, 2019 at 8:02 AM Ahmed S. Darwish wrote:
On Thu, Sep 12, 2019 at 12:34:45PM +0100, Linus Torvalds wrote:
An alternative might be to make getrandom() just return an error
instead of waiting. Sure, fill the buffer with "as random as we
On Sat, Sep 14, 2019 at 8:02 AM Ahmed S. Darwish wrote:
>
> On Thu, Sep 12, 2019 at 12:34:45PM +0100, Linus Torvalds wrote:
> >
> > An alternative might be to make getrandom() just return an error
> > instead of waiting. Sure, fill the buffer with "as random as we can"
> > stuff, but then return
On Sat, Sep 14, 2019 at 11:25:09AM +0200, Ahmed S. Darwish wrote:
> Unfortunately, it only made the early fast init faster, but didn't fix
> the normal crng init blockage :-(
Yeah, I see why; the original goal was to do the fast init so that
using /dev/urandom, even before we were fully
On 9/10/19 12:55 PM, KP Singh wrote:
> From: KP Singh
>
> The LSM creates files in securityfs for each hook registered with the
> LSM.
>
> /sys/kernel/security/bpf/
>
> The initialization of the hooks is done collectively in an internal
> header "hooks.h" which results in:
>
> *
On Sat, Sep 14, 2019 at 9:38 AM H. Nikolaus Schaller wrote:
>
>
> > Am 14.09.2019 um 15:42 schrieb Adam Ford :
> >
> > On Sat, Sep 14, 2019 at 4:20 AM H. Nikolaus Schaller
> > wrote:
> >>
> >>
> >>> Am 13.09.2019 um 17:37 schrieb Adam Ford :
> >>>
> >>> The OMAP3530, AM3517 and DM3730 all show
On 9/10/19 12:55 PM, KP Singh wrote:
> From: KP Singh
>
> Update the libbpf library with functionality to load and
> attach a program type BPF_PROG_TYPE_KRSI.
>
> Since the bpf_prog_load does not allow the specification of an
> expected attach type, it's recommended to use bpf_prog_load_xattr
On 9/14/19 6:41 AM, Jarkko Sakkinen wrote:
>
> The proposed LSM hooks give the granularity to make yes/no decision
> based on the
>
> * The origin of the source of the source for the enclave.
> * The requested permissions for the added or mapped peage.
>
> The hooks to do these checks are
On Thu, Sep 12, 2019 at 07:28:12PM +0300, Alexandru Ardelean wrote:
> +static int adin_set_edpd(struct phy_device *phydev, u16 tx_interval)
> +{
> + u16 val;
> +
> + if (tx_interval == ETHTOOL_PHY_EDPD_DISABLE)
> + return phy_clear_bits(phydev, ADIN1300_PHY_CTRL_STATUS2,
> +
On Thu, Sep 12, 2019 at 07:28:11PM +0300, Alexandru Ardelean wrote:
> The `phy_tunable_id` has been named `ETHTOOL_PHY_EDPD` since it looks like
> this feature is common across other PHYs (like EEE), and defining
> `ETHTOOL_PHY_ENERGY_DETECT_POWER_DOWN` seems too long.
>
> The way EDPD works, is
On Mon, Jan 30, 2017 at 12:05:06PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> Hi everyone,
>
> This small series is preparatory work for a series that I'm working on
> which attempts to establish a formal framework for system restart and
> power off.
>
> Guenter has done a lot of
The PCM draining behavior got broken since the recent refactoring, and
this turned out to be the incorrect expectation of the firmware
behavior regarding "draining". While I expected the "drain" flag at
the stop operation would do processing the queued samples, it seems
rather dropping the
On Thu, Sep 12, 2019 at 08:28:39PM -0700, Florian Fainelli wrote:
> Add support for configuring the per-port egress flooding control for
> both Unicast and Multicast traffic.
>
> Signed-off-by: Florian Fainelli
> ---
> Beneditk,
>
> Do you mind re-testing, or confirming that this patch that I
On Fri, Sep 13, 2019 at 03:55:47PM -0700, Dmitry Torokhov wrote:
> The MDIO device reset line is optional and now that gpiod_get_optional()
> returns proper value when GPIO support is compiled out, there is no
> reason to use fwnode_get_named_gpiod() that I plan to hide away.
>
> Let's switch to
On Sat, Sep 14, 2019 at 01:37:17PM +0200, Borislav Petkov wrote:
> On Sat, Sep 14, 2019 at 01:33:45PM +0300, Alexey Dobriyan wrote:
> > --- a/arch/x86/include/asm/string_64.h
> > +++ b/arch/x86/include/asm/string_64.h
> > @@ -15,7 +15,111 @@ extern void *memcpy(void *to, const void *from, size_t
On 9/10/19 2:59 PM, Dan Carpenter wrote:
On Sun, Sep 08, 2019 at 12:00:26PM +0300, Ivan Safonov wrote >> rtw_malloc
prevents the use of kmemdup/kzalloc and others.
Signed-off-by: Ivan Safonov
---
drivers/staging/rtl8188eu/core/rtw_ap.c| 4 ++--
On Thu, Sep 12, 2019 at 12:34:45PM +0100, Linus Torvalds wrote:
> On Thu, Sep 12, 2019 at 9:25 AM Theodore Y. Ts'o wrote:
> >
> > Hmm, one thought might be GRND_FAILSAFE, which will wait up to two
> > minutes before returning "best efforts" randomness and issuing a huge
> > massive warning if it
> Am 14.09.2019 um 15:42 schrieb Adam Ford :
>
> On Sat, Sep 14, 2019 at 4:20 AM H. Nikolaus Schaller
> wrote:
>>
>>
>>> Am 13.09.2019 um 17:37 schrieb Adam Ford :
>>>
>>> The OMAP3530, AM3517 and DM3730 all show thresholds of 90C and 105C
>>> depending on commercial or industrial
On Fri, 2019-08-23 at 12:50 +, Christophe Leroy wrote:
> On mpc83xx with a QE, IMMR is 2Mbytes.
> On mpc83xx without a QE, IMMR is 1Mbytes.
> Each driver will map a part of it to access the registers it needs.
> Some driver will map the same part of IMMR as other drivers.
>
> In order to
On Tue, 2019-09-10 at 13:34 +0800, Jason Yan wrote:
> Hi Scott,
>
> On 2019/8/28 12:05, Scott Wood wrote:
> > On Fri, 2019-08-09 at 18:07 +0800, Jason Yan wrote:
> > > This series implements KASLR for powerpc/fsl_booke/32, as a security
> > > feature that deters exploit attempts relying on
There is an ongoing discussion on the choice of flag we want to care
about here. Therefore, please don't pull this patch until we reach an
agreement.
Thanks,
Mathieu
- On Sep 13, 2019, at 11:12 AM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> It has been reported by Google
On 9/13/19 6:06 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.9.193 release.
There are 14 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made
On Mon, Sep 09, 2019 at 01:49:06PM -0700, Tao Ren wrote:
> From: Heiner Kallweit
>
> This patch adds support for clause 37 1000Base-X auto-negotiation.
>
> Signed-off-by: Heiner Kallweit
> Signed-off-by: Tao Ren
> Tested-by: René van Dorst
Reviewed-by: Andrew Lunn
Andrew
On 9/13/19 6:07 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.2.15 release.
There are 37 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made
(resending without HTML this time, sorry for the duplicate)
14.09.2019 17:25, Ahmed S. Darwish пишет:
getrandom() has been created as a new and more secure interface for
pseudorandom data requests. Unlike /dev/urandom, it unconditionally
blocks until the entropy pool has been properly
On 9/13/19 6:04 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.73 release.
There are 190 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be
On 9/13/19 6:06 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.144 release.
There are 21 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be
Hi Tejun,
On Sat, Aug 31, 2019 at 6:01 AM Tejun Heo wrote:
>
> Hello,
>
> On Sat, Aug 31, 2019 at 12:03:26PM +0900, Namhyung Kim wrote:
> > Hmm.. it looks hard to use fhandle as the identifier since perf
> > sampling is done in NMI context. AFAICS the encode_fh part seems ok
> > but getting
On Sat, 14 Sep 2019, Atish Patra wrote:
> Thanks for the quick fix. Is there a planned timeline when we can
> remove the deprecated magic ?
If Linus merges this patch, we should probably start the transition in the
bootloaders, QEMU, and user tools as quickly as possible. Probably the
key
On 9/13/19 6:06 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.193 release.
There are 9 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made
Linus,
The following changes since commit f74c2bb98776e2de508f4d607cd519873065118e:
Linux 5.3-rc8 (2019-09-08 13:33:15 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git
tags/riscv/for-v5.3
for you to fetch changes up to
Audio devices needs exact clock rates in order to correctly reproduce
the sound. Until now, only integer factors were used to configure H6
audio PLL which resulted in inexact rates. Fix that by adding support
for fractional factors using sigma-delta modulation look-up table. It
contains values for
1 - 100 of 161 matches
Mail list logo
