> I was thinking about something that looks like serdev from consumer
> side, but instead directly works on struct uart_port, w/o actually
> allocating a tty (and also the funny things like signals, etc).
uart_port is only a subset of tty devices and also relies upon tty for
some of the locking an
On Fri 30-06-17 10:08:03, Linus Torvalds wrote:
> On Fri, Jun 30, 2017 at 6:24 AM, Michal Hocko wrote:
> >
> > FWIW our gcc guys shown an interest in having something to tell the
> > kernel how much the stack can grow at once. They want it for testing of
> > the new stack probing alloca implementa
On Fri, Jun 30, 2017 at 10:20:57AM +0100, Will Deacon wrote:
> On Thu, Jun 29, 2017 at 05:01:20PM -0700, Paul E. McKenney wrote:
> > There is no agreed-upon definition of spin_unlock_wait()'s semantics,
> > and it appears that all callers could do just as well with a lock/unlock
> > pair. This com
On Thu, Jun 29, 2017 at 09:03:42PM -0700, Linus Torvalds wrote:
> On Thu, Jun 29, 2017 at 12:15 PM, Marcelo Tosatti wrote:
> > On Thu, Jun 29, 2017 at 09:13:29AM -0700, Linus Torvalds wrote:
> >>
> >> swait uses special locking and has odd semantics that are not at all
> >> the same as the default
On 06/30/2017 02:25 AM, Alvaro Gamez Machado wrote:
> This IP core has support for mii connectivity to the phy, so be ready to
> connect to it when this is the case.
>
> Signed-off-by: Alvaro Gamez Machado
> ---
> drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 6 +-
> 1 file changed, 5
On Fri, Jun 30, 2017 at 01:16:54PM +0800, Boqun Feng wrote:
> On Thu, Jun 29, 2017 at 09:02:41PM -0700, Paul E. McKenney wrote:
[ . . . ]
> > > > o kernel/task_work.c task_work_run()
> > > > Seems to rely on the acquire semantics only. This is to handle
> > >
> > > I think this on
On Fri, 30 Jun 2017 09:41:18 +0800
Wanpeng Li wrote:
> Hi Luiz,
>
> 2017-06-30 1:15 GMT+08:00 Frederic Weisbecker :
> > Hi,
> >
> > This is a proposition to fix
> > "[BUG nohz]: wrong user and system time accounting":
> > http://lkml.kernel.org/r/20170323165512.60945...@redhat.com
> >
>
On 30 June 2017 at 15:55, Russell King - ARM Linux
wrote:
> On Fri, Jun 30, 2017 at 03:49:41PM +, Ard Biesheuvel wrote:
>>
>>
>> > On 30 Jun 2017, at 15:34, Arnd Bergmann wrote:
>> >
>> > With the new task struct randomization, we can run into a build
>> > failure for certain random seeds:
>>
I'm far from sure that my adjust_reg_min_max_vals() code remains correct
in the face of maybe-signed-maybe-not bounds, even with the checks I've
added in. So this probably has security leaks in it; but it should
suffice for measuring the effect on pruning.
The treat_as_signed part is loosely b
Hi,
On 30-06-17 18:37, Andy Shevchenko wrote:
On Fri, Jun 30, 2017 at 6:57 PM, Benjamin Tissoires
+static const struct i2c_device_id mshw0011_id[] = {
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, mshw0011_id);
->probe_new(), please.
Correct
If I2C framework is _still_ broken we need to
Hello Mark,
Thank you for reviewing the patch. I've used the checkpatch tool and
fixed the warnings provided by the tool. The warnings are in the
function definitions:
1) static void bcm63xx_hsspi_set_cs(struct bcm63xx_hsspi *bs, unsigned
cs, bool active)
2) static void bcm63xx_hsspi_set_clk(st
Jim Baxter writes:
> The CDC-NCM driver can require large amounts of memory to create
> skb's and this can be a problem when the memory becomes fragmented.
>
> This especially affects embedded systems that have constrained
> resources but wish to maximise the throughput of CDC-NCM with 16KiB
> NT
On Fri, Jun 30, 2017 at 8:37 PM, Hans de Goede wrote:
> On 30-06-17 18:37, Andy Shevchenko wrote:
>> On Fri, Jun 30, 2017 at 6:57 PM, Benjamin Tissoires
> ACPI i2c drivers still need an empty i2c_device_id table I've
> fixing this on my TODO but it has been buried in other stuff.
>
> Benjamin if
Many conditions may cause synchronisation to be lost when updating
the perf ring buffer but the end result is still the same: synchronisation
is lost. As such there is no need to increment the lost count for each
condition, just once will suffice.
Signed-off-by: Mathieu Poirier
---
drivers/hwtr
Function etb_disable_hw() is already taking care of unlocking and locking
the coresight access register and as such doesn't need to be placed
within the unlock/lock of function etb_update_buffer().
Signed-off-by: Mathieu Poirier
---
drivers/hwtracing/coresight/coresight-etb10.c | 2 +-
1 file ch
When a buffer overflow happens the synchronisation patckets usually
present at the beginning of the buffer are lost, a situation that
prevents the decoder from knowing the context of the traces being
decoded.
This patch adds a barrier packet to be used by sink IPs when a buffer
overflow condition
Hi,
On 30-06-17 19:40, Andy Shevchenko wrote:
On Fri, Jun 30, 2017 at 8:37 PM, Hans de Goede wrote:
On 30-06-17 18:37, Andy Shevchenko wrote:
On Fri, Jun 30, 2017 at 6:57 PM, Benjamin Tissoires
ACPI i2c drivers still need an empty i2c_device_id table I've
fixing this on my TODO but it has
Register ETMSYNCFR holds the number of by that need to be generated before
periodic synchronisation packets are inserted in the trace stream. By
zeroing out the config structure, the current code effectively disable
periodic synchronization.
This patch simply initialise the recommended value for
These 5 patches address a few issues we've seen with the drivers as
we keep adding new features. The first 3 patches address a
synchronisation problem when trace buffers overflow while the latter
two fix a couple of problems when working ETMv3 tracers.
Regards,
Mathieu
Mathieu Poirier (5):
cor
Internal CoreSight components are rendering trace data in little-endian
format. As such there is no need to convert the data once more, hence
removing the extra step.
Signed-off-by: Mathieu Poirier
---
drivers/hwtracing/coresight/coresight-etb10.c | 12
1 file changed, 4 insertions
On Wed, Jun 28, 2017 at 3:55 PM, Kyle Huey wrote:
> On Wed, Jun 28, 2017 at 10:49 AM, Mark Rutland wrote:
>> On Wed, Jun 28, 2017 at 09:48:27AM -0700, Kyle Huey wrote:
>>> On Wed, Jun 28, 2017 at 3:56 AM, Mark Rutland wrote:
>>> > @@ -6101,6 +6116,12 @@ void perf_prepare_sample(struct perf_event
On Fri, Jun 30, 2017 at 10:26 AM, Michal Hocko wrote:
>
> Ohh, you misunderstood I guess. They wanted that only for internal
> testing (e.g. make sure that everything that matters blows up if it is
> doing something wrong). Absolutely nothing to base any compilator
> decistion on.
Oh, good.
If t
Commit-ID: 2513cbf9d622d85268655bfd787d4f004342cfc9
Gitweb: http://git.kernel.org/tip/2513cbf9d622d85268655bfd787d4f004342cfc9
Author: Josh Poimboeuf
AuthorDate: Fri, 30 Jun 2017 09:09:34 -0500
Committer: Ingo Molnar
CommitDate: Fri, 30 Jun 2017 19:43:50 +0200
objtool: Silence warnings
> Jim Baxter writes:
>
>> The CDC-NCM driver can require large amounts of memory to create
>> skb's and this can be a problem when the memory becomes fragmented.
>>
>> This especially affects embedded systems that have constrained
>> resources but wish to maximise the throughput of CDC-NCM with
On Fri, Jun 30, 2017 at 8:42 PM, Hans de Goede wrote:
> On 30-06-17 19:40, Andy Shevchenko wrote:
>> On Fri, Jun 30, 2017 at 8:37 PM, Hans de Goede
>> wrote:
>>> On 30-06-17 18:37, Andy Shevchenko wrote:
On Fri, Jun 30, 2017 at 6:57 PM, Benjamin Tissoires
> Care to share that? Between me an
On Fri, Jun 30, 2017 at 07:02:20PM +0200, Mike Galbraith wrote:
> On Fri, 2017-06-30 at 10:28 -0400, Josef Bacik wrote:
> > On Thu, Jun 29, 2017 at 08:04:59PM -0700, Joel Fernandes wrote:
> >
> > > That makes sense that we multiply slave's flips by a factor because
> > > its low, but I still didn'
On Fri, Jun 30, 2017 at 12:01 PM, Davidlohr Bueso wrote:
> While going through the driver wake code, I found the
> abuse of BUG_ON to be quite disturbing.
These were coded as BUG_ON to ensure they were addressed. They
do not get raised in any running environment. Switching to WARN_ON
will make
Jim Mattson writes:
> Isn't McAfee DeepSAFE defunct? Are there any other consumers of EPTP
> switching?
I don't know of any real users but I think we should be providing this
functionality to
the L1 hypervisor :)
IIRC, Xen lets you use EPTP switching as part of VM introspection ?
Bandan
>
On Fri, Jun 30, 2017 at 8:55 PM, Andy Shevchenko
wrote:
> On Fri, Jun 30, 2017 at 8:42 PM, Hans de Goede wrote:
>> On 30-06-17 19:40, Andy Shevchenko wrote:
>>> On Fri, Jun 30, 2017 at 8:37 PM, Hans de Goede
>>> wrote:
On 30-06-17 18:37, Andy Shevchenko wrote:
> On Fri, Jun 30, 2017 at
"Baxter, Jim" writes:
> I tested this with printk's to show when the low memory code was triggered
> and the value of ctx->tx_low_mem_val and ctx->tx_low_mem_max_cnt.
> I created a workqueue that slowly used up the atomic memory until the
> code is triggered.
>
> I could add debug prints, though
On Thu, Jun 29, 2017 at 06:23:54PM -0700, Brian Norris wrote:
> mwifiex records information about various channels as it receives scan
> information. It does this by appending to a buffer that was sized
> to the max number of supported channels on any band, but there are
> numerous problems:
>
> (
On Friday 30 June 2017 09:12:37 Finn Thain wrote:
> On Thu, 29 Jun 2017, Ondrej Zary wrote:
> > The write corruption is still there. I'm afraid it can't be fixed
> > without rolling "start" back (or inceasing residual) if an error
> > occured, something like this:
> >
> > --- a/drivers/scsi/g_NCR53
On Fri, 30 Jun 2017, Michal Hocko wrote:
> On Thu 29-06-17 22:25:09, Mikulas Patocka wrote:
> > The __vmalloc function has a parameter gfp_mask with the allocation flags,
> > however it doesn't fully respect the GFP_NOIO and GFP_NOFS flags. The
> > pages are allocated with the specified gfp flag
Hi Brian,
> --
> On Thu, Jun 29, 2017 at 06:23:54PM -0700, Brian Norris wrote:
> > mwifiex records information about various channels as it receives
> scan
> > information. It does this by appending to a buffer that was sized to
>
On Fri, Jun 30, 2017 at 05:28:02PM +1000, Nicholas Piggin wrote:
> On Fri, 30 Jun 2017 10:52:18 +0530
> Abdul Haleem wrote:
>
> > On Fri, 2017-06-30 at 00:45 +1000, Nicholas Piggin wrote:
> > > On Thu, 29 Jun 2017 20:23:05 +1000
> > > Nicholas Piggin wrote:
> > >
> > > > On Thu, 29 Jun 2017 19:
On 6/30/17 9:44 AM, Edward Cree wrote:
I haven't measured the test_progs ones, because I *still* haven't gotten
around to actually setting up a BPF toolchain (it doesn't help that I'm
building everything on a test server that gets reimaged every night to
run our nightly tests...).
then you'r
On Tue, 27 Jun 2017 10:21:43 +0200
Benjamin Gaignard wrote:
> 2017-06-26 22:29 GMT+02:00 William Breathitt Gray :
> > On Sat, Jun 24, 2017 at 09:35:39PM +0100, Jonathan Cameron wrote:
> >>On Wed, 21 Jun 2017 16:30:15 +0200
> >>Fabrice Gasnier wrote:
> >>
> >>> Add support for STM32 Low-Power
David Miller writes:
> From: "Eric W. Biederman"
> Date: Fri, 30 Jun 2017 07:39:01 -0500
>
>> diff --git a/arch/sparc/include/uapi/asm/siginfo.h
>> b/arch/sparc/include/uapi/asm/siginfo.h
>> index 2d9b79ccaa50..6bc5c677e92f 100644
>> --- a/arch/sparc/include/uapi/asm/siginfo.h
>> +++ b/arch/spa
On Fri, Jun 30, 2017 at 06:58:24PM +0300, Andy Shevchenko wrote:
> On Fri, Jun 30, 2017 at 6:45 PM, Arnd Bergmann wrote:
> > Marking sony_laptop_input_keycode_map 'const' sounds like a good
> > idea in principle, but unfortunately causes a compiler warning:
> >
> > drivers/platform/x86/sony-laptop
On Fri, Jun 30, 2017 at 09:34:24AM +0200, Helge Deller wrote:
>
> I see there are some architectures which define TASK_SIZE not as
> multiple of PAGE_SIZE and as 0x for which the (address >=
> TASK_SIZE) check will not trigger:
>
> arch/arm/include/asm/memory.h:#define TASK_SIZE U
On Fri, Jun 30, 2017 at 9:03 AM, Arnd Bergmann wrote:
> With the new task struct randomization, we can run into a build
> failure for certain random seeds:
>
> arch/arm/kernel/entry-armv.S: Assembler messages:
> arch/arm/kernel/entry-armv.S:803: Error: bad immediate value for offset (4096)
>
> Onl
On Fri, 30 Jun 2017 18:26:56 +0200
Fabrice Gasnier wrote:
> On 06/30/2017 03:57 PM, Jonathan Cameron wrote:
> > On Mon, 26 Jun 2017 18:41:36 +0200
> > Fabrice Gasnier wrote:
> >
> >> On 06/24/2017 10:13 PM, Jonathan Cameron wrote:
> >>> On Wed, 21 Jun 2017 16:30:13 +0200
> >>> Fabrice Gasni
Hi,
>
> any objections?
No objection for X-Gene EDAC.
-Loc
El Thu, Jun 22, 2017 at 03:37:23PM -0700 H. Peter Anvin ha dit:
> On 06/22/17 15:31, Matthias Kaehlcke wrote:
> > (removed some non-x86 lists and folks from recipients)
> >
> > El Thu, Mar 16, 2017 at 05:15:17PM -0700 Michael Davidson ha dit:
> >
> >> undef memcpy and friends in boot/string.c so
On 07/01/2017 02:06 AM, Shuah Khan wrote:
> On 06/30/2017 10:52 AM, Paul Elder wrote:
>> On 07/01/2017 01:33 AM, Shuah Khan wrote:
>>> On 06/30/2017 10:13 AM, Paul Elder wrote:
On 06/30/2017 08:18 AM, Shuah Khan wrote:
> This patch series converts breakpoint_test_arm64 to TAP13 output. Use
Thank you for your feedback. I guess when making this patch I had the
preferred coding style in mind, but didn't ask myself if making the code
conform to it would truly improve readability.
I agree with all of your comments. Do you think the best course of
action is to create a new patch with this
On Fri, 30 Jun 2017, Linus Torvalds wrote:
> So use the "enhanced" one for stuff above the 256-byte limit. Not for
> basic probing.
The probing itself uses type1 unconditionally. It just switches over when
mmcfg is the default and no other quirk has been applied.
Nevertheless I zap that commit in
On Tue, Jun 27, 2017 at 12:28 PM, Masami Hiramatsu wrote:
> Use md5sum so that it takes less time of checking
> trace logs update. Since busybox tail/cat takes too
> long time to read the trace log, this uses md5sum
> to check whether trace log is updated or not.
>
> Signed-off-by: Masami Hiramats
On 06/30, Gabriel FERNANDEZ wrote:
>
>
> On 06/30/2017 02:20 AM, Stephen Boyd wrote:
> > On 06/29, Gabriel FERNANDEZ wrote:
> >>
> >> On 06/28/2017 05:59 PM, Stephen Boyd wrote:
> >>> On 06/27, Gabriel FERNANDEZ wrote:
> On 06/22/2017 12:07 AM, Stephen Boyd wrote:
> > readl_poll_timeout?
> -Original Message-
> From: Colin King [mailto:colin.k...@canonical.com]
> Subject: [PATCH][-next] net/mlx5: fix spelling mistake: "Allodating" ->
> "Allocating"
>
> From: Colin Ian King
>
> Trivial fix to spelling mistake in mlx5_core_dbg debug message
>
> Signed-off-by: Colin Ian Kin
> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Subject: [PATCH] [net-next] net/mlx5: include wq.o in non-ethernet build
> for FPGA
>
> Both the ethernet and FPGA portions of MLX5 now require the wq functions,
> and we get a link error when CONFIG_MLX5_CORE_EN is disabl
On Fri, 30 Jun 2017 20:50:45 +0200
Denys Vlasenko wrote:
> On Tue, Jun 27, 2017 at 12:28 PM, Masami Hiramatsu
> wrote:
> > Use md5sum so that it takes less time of checking
> > trace logs update. Since busybox tail/cat takes too
> > long time to read the trace log, this uses md5sum
> > to check
Broadcom BCM53573 SoCs actually have 32 GPIOs, and not 16.
Fixes: 3f37ec79dd21 ("bcma: support BCM53573 series of wireless SoCs")
Signed-off-by: Florian Fainelli
---
drivers/bcma/driver_gpio.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/bcma/driver_gpio.c b/drivers/bcma/driver_gp
- Original Message -
> From: "Jim Mattson"
> To: "Bandan Das"
> Cc: "kvm list" , "Paolo Bonzini" ,
> "LKML"
> Sent: Friday, June 30, 2017 7:06:43 PM
> Subject: Re: [PATCH 0/2] Expose VMFUNC to the nested hypervisor
>
> Isn't McAfee DeepSAFE defunct? Are there any other consumers of E
On Wed, Jun 28, 2017 at 04:01:47PM -0600, Ross Zwisler wrote:
> When servicing mmap() reads from file holes the current DAX code allocates
> a page cache page of all zeroes and places the struct page pointer in the
> mapping->page_tree radix tree. This has three major drawbacks:
>
> 1) It consume
On Fri, Jun 30, 2017 at 10:16:15AM -0700, Linus Torvalds wrote:
> On Fri, Jun 30, 2017 at 7:30 AM, Thomas Gleixner wrote:
> >> But MCFG problems were a long time ago and noone uses these systems
> >> anymore,
> >> so perhaps he is right.
> >
> > The obvious solution to this is to force type 1 for
On Thu, Jun 29, 2017 at 08:42:23PM -0500, Eric W. Biederman wrote:
> Andrei Vagin writes:
>
> > On Thu, Jun 29, 2017 at 12:06 PM, Eric W. Biederman
> > wrote:
> >> Andrei Vagin writes:
> >>
> >>> Hello,
> >>>
> >>> We run CRIU tests on linus' tree and today we found this issue.
> >>>
> >>> CRIU
From: Kuppuswamy Sathyanarayanan
Added maintainer info for Whiskey Cove PMIC GPIO driver.
Signed-off-by: Kuppuswamy Sathyanarayanan
---
MAINTAINERS | 6 ++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 09b5ab6..f76c349 100644
--- a/MAINTAINERS
+++ b/MAINTAI
On 06/30, Paul E. McKenney wrote:
>
> On Fri, Jun 30, 2017 at 05:20:10PM +0200, Oleg Nesterov wrote:
> >
> > I do not think the overhead will be noticeable in this particular case.
> >
> > But I am not sure I understand why do we want to unlock_wait. Yes I agree,
On 06/30, Chunyan Zhang wrote:
> Hi Stephen,
>
> On 30 June 2017 at 09:44, Stephen Boyd wrote:
> > On 06/22, Chunyan Zhang wrote:
> >> On 20 June 2017 at 09:37, Stephen Boyd wrote:
> >> > On 06/18, Chunyan Zhang wrote:
> >> >> + pll->factors[member].width
> >> >> +
> >> >> +#define pmask(pll
On 06/30, Gregory CLEMENT wrote:
>
> Hi Stephen,
>
> As seen on Tuesday this is the pull request for the remaining binding
> documentation which depends on the documentation already applied in your
> tree.
>
> Thanks for taking care of it,
>
> Gregory
>
> The following changes since commit 7e5
On Fri, Jun 30, 2017 at 8:58 PM, Ilan Tayari wrote:
>> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/Makefile
>> b/drivers/net/ethernet/mellanox/mlx5/core/Makefile
>> index ca367445f864..50fe9e3c5dc2 100644
>> --- a/drivers/net/ethernet/mellanox/mlx5/core/Makefile
>> +++ b/drivers/net/ethe
Hi!
I noticed that nf_conntrack leaks kernel addresses, it uses the memory address
as identifier used for generating conntrack and expect ids..
Since these ids are also visible to unprivileged users via network namespaces
I suggest reverting these commits:
commit 7f85f914721ffcef382a57995182916bd
Commit-ID: 79298acc4ba097e9ab78644e3e38902d73547c92
Gitweb: http://git.kernel.org/tip/79298acc4ba097e9ab78644e3e38902d73547c92
Author: Vikas Shivappa
AuthorDate: Mon, 26 Jun 2017 11:55:49 -0700
Committer: Thomas Gleixner
CommitDate: Fri, 30 Jun 2017 21:20:00 +0200
x86/intel_rdt: Fix me
On 06/29/2017 01:03 AM, Tony Lindgren wrote:
> * Vignesh R [170628 21:21]:
>>
>>
>> On Thursday 29 June 2017 05:01 AM, Strashko, Grygorii wrote:
>>> IRQ_NOAUTOEN can't be used with shared IRQs and Kernel now will triggers
>>> warning if it happns, since commit 04c848d39879 ("genirq: Warn when
>>
Richard Weinberger wrote:
> Hi!
>
> I noticed that nf_conntrack leaks kernel addresses, it uses the memory address
> as identifier used for generating conntrack and expect ids..
> Since these ids are also visible to unprivileged users via network namespaces
> I suggest reverting these commits:
W
> One problem with this approach is that restarting the transaction handle will
> make the xattr update non-atomic, which could be a real problem for some
> workloads. For example, ACLs or SELinux or fscrypt xattrs being added in
> a separate transaction from file creation, or being modified (dele
Hi Tejun, Sergei,
Quoting Tejun Heo :
On Fri, Jun 30, 2017 at 12:42:38PM +0300, Sergei Shtylyov wrote:
Hello!
On 6/30/2017 8:22 AM, Gustavo A. R. Silva wrote:
> Print error message and propagate the return value of
> platform_get_irq on failure.
You should have probably mentioned that th
-Original Message-
From: Arnaldo Carvalho de Melo [mailto:a...@kernel.org]
Sent: Friday, June 30, 2017 5:54 PM
To: Hunter, Adrian
Cc: Andi Kleen ; linux-kernel@vger.kernel.org
Subject: Re: [PATCH V2 25/37] perf script: Add synthesized Intel PT power and
ptwrite events
> Em Fri, Jun 30,
On 06/30/2017 10:36 PM, Gustavo A. R. Silva wrote:
> Print error message and propagate the return value of
> platform_get_irq on failure.
You should have probably mentioned that this function no longer returns 0
on error.
Yeah, the patches looks good to me but I'd really appreciate more
co
Florian,
Am 30.06.2017 um 21:35 schrieb Florian Westphal:
> Richard Weinberger wrote:
>> Hi!
>>
>> I noticed that nf_conntrack leaks kernel addresses, it uses the memory
>> address
>> as identifier used for generating conntrack and expect ids..
>> Since these ids are also visible to unprivileged
Quoting "Gustavo A. R. Silva" :
Hi Tejun, Sergei,
Quoting Tejun Heo :
On Fri, Jun 30, 2017 at 12:42:38PM +0300, Sergei Shtylyov wrote:
Hello!
On 6/30/2017 8:22 AM, Gustavo A. R. Silva wrote:
Print error message and propagate the return value of
platform_get_irq on failure.
You should
Switch to the new ac97 bus support in sound/ac97 instead of the legacy
snd_ac97 one.
Signed-off-by: Robert Jarzmik
---
Since v1: split into 2 patches, the former being XXX ac97 codec agnostic
Since v2: fix driver unregistration
---
sound/arm/Kconfig | 1 -
sound/soc/pxa/Kconfig
wm97xx-core does several things in it initialization :
- touchscreen input device setup
- battery device creation
As the wm97xx is actually a multi-function device handling an audio
codec, a touchscreen, a gpio block and an ADC, reshape the probing to
isolate what is truly input/touchscreen spec
Hi Lars, Mark, Charles, Lee,
This is a resend of the v2, with patch 1 added (forgotten in v2). Patch 12 was
slightly modified after module unloading tests, and Dmitry acks were added.
This serie has been stalled for almost one year, as I wasn't feeling that
well lately. I'm quite better now, so l
The WM9705, WM9712 and WM9713 are highly integrated codecs, with an
audio codec, DAC and ADC, GPIO unit and a touchscreen interface.
Historically the support was spread across drivers/input/touchscreen and
sound/soc/codecs. The sharing was done through ac97 bus sharing. This
model will not withsta
Add a private data structure. This is a preparation for a codec which
would need an another data on top of snd_ac97, which will be the case
when an MFD wm97xx device will probe wm9705.
Signed-off-by: Robert Jarzmik
---
sound/soc/codecs/wm9705.c | 36
1 file c
Split out from the ac97_codec.h the ac97 generic registers, which can be
used by a codec, typically a generic ac97 codec, and by the ac97 bus, to
scan an ac97 AC-Link.
This split encompasses all the AC97 standard registers, but not the
codec specific ones.
In order to have a clean split between f
This adds support for the new AC97 bus code, which discovers the devices
rather than uses platform data.
As part of this discovery, it enables a multi-function device wm97xx,
which supports touchscreen, battery, ADC and an audio codec. This patch
adds the code to bind the touchscreen "cell" as the
AC97 is a bus for sound usage. It enables for a AC97 AC-Link to link one
controller to 0 to 4 AC97 codecs.
The goal of this new implementation is to implement a device/driver
model for AC97, with an automatic scan of the bus and automatic
discovery of AC97 codec devices.
Signed-off-by: Robert Jar
All pxa library functions don't use the input parameters for nothing but
slot number. This simplifies their prototypes, and makes them usable by
both the legacy ac97 bus and the new ac97 bus.
Signed-off-by: Robert Jarzmik
---
include/sound/pxa2xx-lib.h | 15 +--
sound/arm/pxa2xx-ac9
Add the new ac97 bus support, with ac97 bus automatic probing.
Signed-off-by: Robert Jarzmik
Acked-by: Charles Keepax
---
sound/Kconfig | 2 ++
sound/Makefile| 1 +
sound/soc/Kconfig | 4
3 files changed, 7 insertions(+)
diff --git a/sound/Kconfig b/sound/Kconfig
index ee2e69a9ecd
On Thu, Jun 29, 2017 at 10:32:49PM -0700, John Hubbard wrote:
> On 06/28/2017 11:00 AM, Jérôme Glisse wrote:
> >
> > Patchset is on top of git://git.cmpxchg.org/linux-mmotm.git so i
> > test same kernel as kbuild system, git branch:
> >
> > https://cgit.freedesktop.org/~glisse/linux/log/?h=hmm-v2
On Fri, 30 Jun 2017, Oleg Nesterov wrote:
> On 06/30, Paul E. McKenney wrote:
> >
> > On Fri, Jun 30, 2017 at 05:20:10PM +0200, Oleg Nesterov wrote:
> > >
> > > I do not think the overhead will be noticeable in this particular case.
> > >
> > > But I am not sure I understand why do we want to unlo
> If i understood all correctly,
> zstd can compress (decompress) data in way compatible with gzip (zlib)
> Do that also true for in kernel library?
The zstd command line tool can decompress gzip/zlib compressed data, and
can compress in the gzip format. However, the zstd format is not compatible
Hi Sergei,
Quoting Sergei Shtylyov :
On 06/30/2017 10:36 PM, Gustavo A. R. Silva wrote:
Print error message and propagate the return value of
platform_get_irq on failure.
You should have probably mentioned that this function no longer
returns 0
on error.
Yeah, the patches looks good
On 06/29/2017 09:16 AM, Linus Walleij wrote:
> On Tue, Jun 27, 2017 at 10:43 PM, Grygorii Strashko
> wrote:
>
>> And my opinion is still the same here - It should be perfectly valid to
>> create
>> mappings from gpio_to_irq() to handle properly orthogonality of gpiochip and
>> gpio-irqchip fun
Add support for the new ac97 bus model, where devices are automatically
discovered on AC-Links.
Signed-off-by: Robert Jarzmik
---
sound/soc/codecs/Kconfig | 3 ++-
sound/soc/codecs/wm9712.c | 37 -
2 files changed, 26 insertions(+), 14 deletions(-)
diff --g
Add support for the new ac97 bus model, where devices are automatically
discovered on AC-Links.
Signed-off-by: Robert Jarzmik
---
sound/soc/codecs/Kconfig | 3 ++-
sound/soc/codecs/wm9713.c | 39 +++
2 files changed, 29 insertions(+), 13 deletions(-)
diff -
Add support for the new ac97 bus model, where devices are automatically
discovered on AC-Links.
Signed-off-by: Robert Jarzmik
---
sound/soc/codecs/Kconfig | 3 ++-
sound/soc/codecs/wm9705.c | 35 +++
2 files changed, 25 insertions(+), 13 deletions(-)
diff --git
Richard Weinberger wrote:
> Florian,
>
> Am 30.06.2017 um 21:35 schrieb Florian Westphal:
> > Richard Weinberger wrote:
> >> Hi!
> >>
> >> I noticed that nf_conntrack leaks kernel addresses, it uses the memory
> >> address
> >> as identifier used for generating conntrack and expect ids..
> >> S
platform_get_irq() returns an error code, but the sata_rcar driver
ignores it and always returns -ENODEV. This is not correct, and
prevents -EPROBE_DEFER from being propagated properly. Also,
notice that platform_get_irq() no longer returns 0 on error.
Print and propagate the return value of platf
On Fri, Jun 30, 2017 at 09:21:23PM +0200, Oleg Nesterov wrote:
> On 06/30, Paul E. McKenney wrote:
> >
> > On Fri, Jun 30, 2017 at 05:20:10PM +0200, Oleg Nesterov wrote:
> > >
> > > I do not think the overhead will be noticeable in this particular case.
> > >
> > > But I am not sure I understand wh
On 06/30/2017 10:46 PM, Gustavo A. R. Silva wrote:
Print error message and propagate the return value of
platform_get_irq on failure.
You should have probably mentioned that this function no longer returns 0
on error.
Yeah, the patches looks good to me but I'd really appreciate more
contex
On Fri, Jun 30, 2017 at 03:50:33PM -0400, Alan Stern wrote:
> On Fri, 30 Jun 2017, Oleg Nesterov wrote:
>
> > On 06/30, Paul E. McKenney wrote:
> > >
> > > On Fri, Jun 30, 2017 at 05:20:10PM +0200, Oleg Nesterov wrote:
> > > >
> > > > I do not think the overhead will be noticeable in this particul
On Fri, 30 Jun 2017 21:59:01 +0200,
Gustavo A. R. Silva wrote:
>
> platform_get_irq() returns an error code, but the sata_rcar driver
> ignores it and always returns -ENODEV.
Which driver? A copy&paste error?
Takashi
> This is not correct, and
> prevents -EPROBE_DEFER from being propagated pr
Hi Takashi,
Quoting Takashi Iwai :
On Fri, 30 Jun 2017 21:59:01 +0200,
Gustavo A. R. Silva wrote:
platform_get_irq() returns an error code, but the sata_rcar driver
ignores it and always returns -ENODEV.
Which driver? A copy&paste error?
Yep, I'm already working on v2 of this patch, whi
platform_get_irq() returns an error code, but the intel_hdmi_audio
driver ignores it and always returns -ENODEV. This is not correct,
and prevents -EPROBE_DEFER from being propagated properly. Also,
notice that platform_get_irq() no longer returns 0 on error.
Print error message and propagate the
On Fri, Jun 30, 2017 at 01:02:48PM -0700, Paul E. McKenney wrote:
> On Fri, Jun 30, 2017 at 09:21:23PM +0200, Oleg Nesterov wrote:
> > On 06/30, Paul E. McKenney wrote:
> > >
> > > On Fri, Jun 30, 2017 at 05:20:10PM +0200, Oleg Nesterov wrote:
> > > >
> > > > I do not think the overhead will be not
Florian,
Am 30.06.2017 um 21:55 schrieb Florian Westphal:
>>> Why not use a hash of the address?
>>
>> Would also work. Or xor it with a random number.
>>
>> On the other hand, for user space it would be more useful when the conntrack
>> id
>> does not repeat that often. That's why I favor the go
501 - 600 of 763 matches
Mail list logo
