On Wed, 2017-12-13 at 09:20 -0500, Jeff Layton wrote:
> From: Jeff Layton
>
> At this point, we know that "now" and the file times may differ, and we
> suspect that the i_version has been flagged to be bumped. Attempt to
> bump the i_version, and only mark the inode dirty if that actually
> occur
On Fri 15-12-17 13:51:04, Arnd Bergmann wrote:
> When the down_read_trylock() fails, 'vma' has not been initialized
> yet, which gcc now warns about:
>
> mm/khugepaged.c: In function 'khugepaged':
> mm/khugepaged.c:1659:25: error: 'vma' may be used uninitialized in this
> function [-Werror=maybe-
> Warning (unit_address_format): Node /XXX unit name should not have leading
> "0x"
>
> and
>
> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
Humm, it actually looks like the compiler is broken. None of the lines
you are changing in this, or the orion5x file, hav
On Fri, Dec 15, 2017 at 01:46:42PM +0100, Mathieu Malaterre wrote:
> Improve the DTS files by removing all the leading "0x" and zeros to fix the
...
> };
>
> - uboot_env@3F000 {
> + uboot_env@3f000 {
> r
Hello Tejun,
Doing a 'perf record' on an application using GPIOs a lot, I discovered
that most of the time spent in the read() system call of the 'value'
sysfs file of that GPIO (which returns "0\n" or "1\n") is indeed spent
in memset() zeroing a buffer of size PAGE_SIZE for a 2 bytes read:
On Wed, 2017-12-13 at 09:20 -0500, Jeff Layton wrote:
> From: Jeff Layton
>
> We only really need to update i_version if someone has queried for it
> since we last incremented it. By doing that, we can avoid having to
> update the inode if the times haven't changed.
>
> If the times have changed
On Fri, Dec 15, 2017 at 12:03:31PM +, Patrick Bellasi wrote:
> So, by moving util_est right after sched_avg, here is what we get (with some
> lines to better highlight 64B boundaries):
>
> const struct sched_class * sched_class;
>/* 152
On Fri, Dec 15, 2017 at 01:46:21PM +0100, Mathieu Malaterre wrote:
> Improve the DTS files by removing all the leading "0x" and zeros to fix the
> following dtc warnings:
>
> Warning (unit_address_format): Node /XXX unit name should not have leading
> "0x"
>
> and
>
> Warning (unit_address_form
Hi,
commit 1959a60182f4 ("x86/dumpstack: Pin the target stack when dumping
it") slightly changed the behaviour of stack traces dumping for zombie
tasks.
Before the commit (well, this is older SLE12 kernel, but that should not
matter), if one called 'cat /proc//stack', they would get
something
On Fri, Dec 15, 2017 at 12:22:06PM +0100, Sebastian Gottschall wrote:
> kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.88-rc1.gz
>
> is missing.
> same for
> 4.4
Very odd. I've pushed all of the -rc patches out again, maybe the
mirroring is taking a while to hit the public side of the
Improve the DTS files by removing all the leading "0x" and zeros to fix the
following dtc warnings:
Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
and
Warning (unit_address_format): Node /XXX unit name should not have leading 0s
Converted using the following com
Improve the DTS files by removing all the leading "0x" and zeros to fix the
following dtc warnings:
Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
and
Warning (unit_address_format): Node /XXX unit name should not have leading 0s
Converted using the following com
On Fri, Dec 15, 2017 at 12:14:17PM +, Patrick Bellasi wrote:
> On 13-Dec 17:16, Peter Zijlstra wrote:
> > > + /*
> > > + * Skip update of task's estimated utilization when its EWMA is already
> > > + * ~1% close to its last activation value.
> > > + */
> > > + util_est = p->util_est.ewma;
>
Improve the DTS files by removing all the leading "0x" and zeros to fix the
following dtc warnings:
Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
and
Warning (unit_address_format): Node /XXX unit name should not have leading 0s
Converted using the following com
Improve the DTS files by removing all the leading "0x" and zeros to fix the
following dtc warnings:
Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
and
Warning (unit_address_format): Node /XXX unit name should not have leading 0s
Converted using the following com
Improve the DTS files by removing all the leading "0x" and zeros to fix the
following dtc warnings:
Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
and
Warning (unit_address_format): Node /XXX unit name should not have leading 0s
Converted using the following com
Improve the DTS files by removing all the leading "0x" and zeros to fix the
following dtc warnings:
Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
and
Warning (unit_address_format): Node /XXX unit name should not have leading 0s
Converted using the following com
Hi Arnd,
On 15/12/2017 13:48, Arnd Bergmann wrote:
> The pinconf_generic_dt_free_map and pinconf_generic_dt_node_to_map_group
> functions are only defined when CONFIG_OF is set:
>
> drivers/pinctrl/pinctrl-axp209.c:312:21: error:
> 'pinconf_generic_dt_node_to_map_group' undeclared here (not in a
When the down_read_trylock() fails, 'vma' has not been initialized
yet, which gcc now warns about:
mm/khugepaged.c: In function 'khugepaged':
mm/khugepaged.c:1659:25: error: 'vma' may be used uninitialized in this
function [-Werror=maybe-uninitialized]
Presumable we are not supposed to call find
The newly introduced driver has optional suspend/resume functions,
causing a warning when CONFIG_PM is disabled:
drivers/gpu/drm/tegra/hub.c:749:12: error: 'tegra_display_hub_resume' defined
but not used [-Werror=unused-function]
drivers/gpu/drm/tegra/hub.c:733:12: error: 'tegra_display_hub_suspe
Improve the DTS files by removing all the leading "0x" and zeros to fix the
following dtc warnings:
Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
and
Warning (unit_address_format): Node /XXX unit name should not have leading 0s
Converted using the following com
Improve the DTS files by removing all the leading "0x" and zeros to fix the
following dtc warnings:
Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
and
Warning (unit_address_format): Node /XXX unit name should not have leading 0s
Converted using the following com
Improve the DTS files by removing all the leading "0x" and zeros to fix the
following dtc warnings:
Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
and
Warning (unit_address_format): Node /XXX unit name should not have leading 0s
Converted using the following com
Improve the DTS files by removing all the leading "0x" and zeros to fix the
following dtc warnings:
Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
and
Warning (unit_address_format): Node /XXX unit name should not have leading 0s
Converted using the following com
Hi,
This is a known issue. Could you try out this patch to see if that
would fix this issue for you?
https://patchwork.freedesktop.org/series/35389/
On Fri, 2017-12-15 at 17:08 +0530, Jaswinder Singh Rajput wrote:
> Hello friends,
>
> I am getting multiple warnings in i915/intel_audio.c . I am
Hi Mathieu,
On Fri, Dec 15, 2017 at 10:46 AM, Mathieu Malaterre wrote:
reg = <0x6C>;
> diff --git a/arch/arm/boot/dts/imx7d.dtsi b/arch/arm/boot/dts/imx7d.dtsi
> index 4d308d17f040..369d5a166b3e 100644
> --- a/arch/arm/boot/dts/imx7d.dtsi
> +++ b/arch/arm/boot/dts/imx7d.dtsi
> @@
Improve the DTS files by removing all the leading "0x" and zeros to fix the
following dtc warnings:
Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
and
Warning (unit_address_format): Node /XXX unit name should not have leading 0s
Converted using the following com
Improve the DTS files by removing all the leading "0x" and zeros to fix the
following dtc warnings:
Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
and
Warning (unit_address_format): Node /XXX unit name should not have leading 0s
Converted using the following com
Improve the DTS files by removing all the leading "0x" and zeros to fix the
following dtc warnings:
Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
and
Warning (unit_address_format): Node /XXX unit name should not have leading 0s
Converted using the following com
Improve the DTS files by removing all the leading "0x" and zeros to fix the
following dtc warnings:
Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
and
Warning (unit_address_format): Node /XXX unit name should not have leading 0s
Converted using the following com
The pinconf_generic_dt_free_map and pinconf_generic_dt_node_to_map_group
functions are only defined when CONFIG_OF is set:
drivers/pinctrl/pinctrl-axp209.c:312:21: error:
'pinconf_generic_dt_node_to_map_group' undeclared here (not in a function); did
you mean 'pinconf_generic_params'?
drivers/pi
Improve the DTS files by removing all the leading "0x" and zeros to fix the
following dtc warnings:
Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
and
Warning (unit_address_format): Node /XXX unit name should not have leading 0s
Converted using the following com
Some Cherry Trail boards have a dependency between the SDHCI host
controller used for SD cards and an external PMIC accessed via I2C. Add a
device link between the SDHCI host controller (consumer) and the I2C
adapter (supplier).
This patch depends on a fix to devices links, namely commit 0ff26c662
Improve the DTS files by removing all the leading "0x" and zeros to fix the
following dtc warnings:
Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
and
Warning (unit_address_format): Node /XXX unit name should not have leading 0s
Converted using the following com
A cleanup left an unused label behind:
drivers/misc/mic/vop/vop_vringh.c: In function 'vop_ioctl':
drivers/misc/mic/vop/vop_vringh.c:1001:1: error: label 'done' defined but not
used [-Werror=unused-label]
This cleans it up as well.
Fixes: 30b7a2c19e29 ("misc: mic: Use memdup_user() as a cleanup
Improve the DTS files by removing all the leading "0x" and zeros to fix the
following dtc warnings:
Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
and
Warning (unit_address_format): Node /XXX unit name should not have leading 0s
Converted using the following com
Improve the DTS files by removing all the leading "0x" and zeros to fix the
following dtc warnings:
Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
and
Warning (unit_address_format): Node /XXX unit name should not have leading 0s
Converted using the following com
Improve the DTS files by removing all the leading "0x" and zeros to fix the
following dtc warnings:
Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
and
Warning (unit_address_format): Node /XXX unit name should not have leading 0s
Converted using the following com
From: Borislav Petkov
No need to setup those during boot on !Intel vendors.
Signed-off-by: Borislav Petkov
Cc: Linus Torvalds
Cc: Andy Lutomirsky
Cc: Peter Zijlstra
Cc: Dave Hansen
Cc: Greg KH
Cc: keesc...@google.com
Cc: hu...@google.com
Cc: Brian Gerst
Cc: Josh Poimboeuf
Cc: Denys Vlase
Improve the DTS files by removing all the leading "0x" and zeros to fix the
following dtc warnings:
Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
and
Warning (unit_address_format): Node /XXX unit name should not have leading 0s
Converted using the following com
Improve the DTS files by removing all the leading "0x" and zeros to fix the
following dtc warnings:
Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
and
Warning (unit_address_format): Node /XXX unit name should not have leading 0s
Converted using the following com
Improve the DTS files by removing all the leading "0x" and zeros to fix the
following dtc warnings:
Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
and
Warning (unit_address_format): Node /XXX unit name should not have leading 0s
Converted using the following com
Improve the DTS files by removing all the leading "0x" and zeros to fix the
following dtc warnings:
Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
and
Warning (unit_address_format): Node /XXX unit name should not have leading 0s
Converted using the following com
Improve the DTS files by removing all the leading "0x" and zeros to fix the
following dtc warnings:
Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
and
Warning (unit_address_format): Node /XXX unit name should not have leading 0s
Converted using the following com
Improve the DTS files by removing all the leading "0x" and zeros to fix the
following dtc warnings:
Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
and
Warning (unit_address_format): Node /XXX unit name should not have leading 0s
Converted using the following com
On Fri, Dec 15, 2017 at 1:18 PM, Mathieu Malaterre wrote:
>> As discussed with Krzysztof, I've split the ARM patch into subarch.
>> Please drop this one.
>
> Hum...looks like my internet provider just blacklisted me for too many
> recipient in the mail. I'll do my best to resolve this, and send th
* Randy Dunlap wrote:
> From: Randy Dunlap
>
> Update x86-opcode-map.txt based on the October 2017 Intel SDM publication.
> Correct INVPID to INVVPID.
> Add UD0 and UD1 instruction opcodes.
>
> Signed-off-by: Randy Dunlap
> Cc: Masami Hiramatsu
> Cc: Masami Hiramatsu
> Cc: Josh Poimboeuf
On Thu, Dec 14, 2017 at 08:22:14PM -0800, Matthew Wilcox wrote:
> On Mon, Dec 11, 2017 at 03:10:22PM -0800, Randy Dunlap wrote:
> > > +A freshly-initialised XArray contains a ``NULL`` pointer at every index.
> > > +Each non-``NULL`` entry in the array has three bits associated with
> > > +it called
On 12/15/17 4:58 AM, Andy Shevchenko wrote:
On Thu, 2017-12-14 at 18:44 -0600, Pierre-Louis Bossart wrote:
PCI/ACPI selections should not happen in Kconfig for machine drivers,
move to SOC selections.
Add distinction between PCI and ACPI HiFi2 platforms and help text.
There should be no functi
On Fri, 15 Dec 2017 11:40:04 +
Mark Rutland wrote:
> Hi,
>
> On Thu, Dec 14, 2017 at 09:01:20PM +0100, Boris Brezillon wrote:
> > On Wed, 13 Dec 2017 16:57:50 -0600
> > Rob Herring wrote:
> > > On Wed, Dec 13, 2017 at 12:53 PM, Alexandre Belloni
> > > wrote:
>
> > > > The clocksource
On 12/15/17 5:07 AM, Takashi Iwai wrote:
On Fri, 15 Dec 2017 01:44:43 +0100,
Pierre-Louis Bossart wrote:
+config SND_SOC_ACPI_INTEL_MATCH
+ tristate
+ depends on X86 && ACPI
+ select SND_SOC_ACPI
An item that is selected by others can only select, not depend.
The depends nee
On 12/08/2017 10:42 AM, Jason Yan wrote:
> There are two places queuing the disco event DISCE_REVALIDATE_DOMAIN.
> One is in sas_porte_broadcast_rcvd() and uses sas_chain_event() to queue
> the event. The other is in sas_enable_revalidation() and uses
> sas_queue_event() to queue the event. We have
On 12/08/2017 10:42 AM, Jason Yan wrote:
> In commit 87c8331fcf72 ("[SCSI] libsas: prevent domain rediscovery
> competing with ata error handling") introduced disco mutex to prevent
> rediscovery competing with ata error handling and put the whole
> revalidation in the mutex. But the rphy add/remov
On 12/08/2017 10:42 AM, Jason Yan wrote:
> Now we are processing sas event and discover event in different workqueues.
> It's safe to wait the discover event done in the sas event work. Use
> flush_workqueue() to insure the disco and revalidate events processed
> synchronously so that the whole dis
On 12/08/2017 10:42 AM, Jason Yan wrote:
> Now all libsas works are queued to scsi host workqueue,
> include sas event work post by LLDD and sas discovery
> work, and a sas hotplug flow may be divided into several
> works, e.g libsas receive a PORTE_BYTES_DMAED event,
> currently we process it as f
Make sure the IO domain support is active. This requires to enable
Adaptive Voltage Scaling class support too.
Without Rockchip IO domain support the internal level shifter on the RK3399
will be misconfigured if used in the other voltage domain then the default.
Signed-off-by: Klaus Goger
---
Am 14.12.2017 um 22:30 schrieb David Rientjes:
Commit 4d4bbd8526a8 ("mm, oom_reaper: skip mm structs with mmu notifiers")
prevented the oom reaper from unmapping private anonymous memory with the
oom reaper when the oom victim mm had mmu notifiers registered.
The rationale is that doing mmu_noti
On 12/08/2017 10:42 AM, Jason Yan wrote:
> Add a sysfs attr that LLDD can configure it for every host. We made
> a example in hisi_sas. Other LLDDs using libsas can implement it if
> they want.
>
> Suggested-by: Hannes Reinecke
> Signed-off-by: Jason Yan
> CC: John Garry
> CC: Johannes Thumshir
On Fri, Dec 15, 2017 at 12:19 PM, Mathieu Malaterre wrote:
> On Fri, Dec 15, 2017 at 9:59 AM, Krzysztof Kozlowski wrote:
>> On Thu, Dec 14, 2017 at 5:53 PM, Mathieu Malaterre wrote:
>>> Improve the DTS files by removing all the leading "0x" and zeros to fix the
>>> following dtc warnings:
>>>
>>
Am 15.12.2017 um 11:53 schrieb Colin King:
From: Colin Ian King
The null check on aconnector->base.edid_blob_ptr->data is redundant
since data is an array and can never be null. Remove it.
Detected by CoverityScan, CID#1460369 ("Array compared against 0")
Signed-off-by: Colin Ian King
Ack
On 12/08/2017 10:42 AM, Jason Yan wrote:
> If the PHY burst too many events, we will alloc a lot of events for the
> worker. This may leads to memory exhaustion.
>
> Dan Williams suggested to shut down the PHY if the events reached the
> threshold, because in this case the PHY may have gone into s
On 12/08/2017 10:42 AM, Jason Yan wrote:
> Now libsas hotplug work is static, every sas event type has its own
> static work, LLDD driver queues the hotplug work into shost->work_q.
> If LLDD driver burst posts lots hotplug events to libsas, the hotplug
> events may pending in the workqueue like
>
On 13-Dec 17:16, Peter Zijlstra wrote:
> On Tue, Dec 05, 2017 at 05:10:16PM +, Patrick Bellasi wrote:
> > +static inline void util_est_dequeue(struct task_struct *p, int flags)
> > +{
> > + struct cfs_rq *cfs_rq = &task_rq(p)->cfs;
> > + unsigned long util_last = task_util(p);
> > + bool
On 12/12/2017 11:38 AM, Abdul Haleem wrote:
> Hi,
>
> Off late we are seeing cpu stalls messages while mpt3sas driver unbind
> on powerpc machine for both mainline and linux-next kernels
>
> Machine Type: Power 8 Bare-metal
> Kernel version: 4.15.0-rc2
> config: attached.
> test: driver unbind
>
On 12/12/17 23:51, Boris Ostrovsky wrote:
> Commit f5775e0b6116 ("x86/xen: discard RAM regions above the maximum
> reservation") left host memory not assigned to dom0 as available for
> memory hotplug.
>
> Unfortunately this also meant that those regions could be used by
> others. Specifically, co
On 13-Dec 18:03, Peter Zijlstra wrote:
> On Wed, Dec 13, 2017 at 04:36:53PM +, Patrick Bellasi wrote:
> > On 13-Dec 17:19, Peter Zijlstra wrote:
> > > On Tue, Dec 05, 2017 at 05:10:16PM +, Patrick Bellasi wrote:
> > > > @@ -562,6 +577,12 @@ struct task_struct {
> > > >
> > > > con
Hi
Some basic questions about DT, which I'm not expert of.
On Mon, Dec 04, 2017 at 06:39:16PM +0100, Javier Martinez Canillas wrote:
> The commit 21dc02eab989 ("tpm/tpm_i2c_infineon.c: Add OF attributes type
> and name to the of_device_id table entries") added type and name fields
> to the OF dev
On Fri, Dec 15, 2017 at 1:21 AM, Ben Hutchings
wrote:
> On Mon, 2017-11-27 at 11:30 -0800, Deepa Dinamani wrote:
>> get/put_timespec64() interfaces will eventually be used for
>> conversions between the new y2038 safe struct __kernel_timespec
>> and struct timespec64.
>>
>> The new y2038 safe sysc
On 15/12/17 11:10, Adrian Hunter wrote:
> On 14/12/17 16:16, Andy Shevchenko wrote:
>> On Thu, 2017-12-07 at 11:03 +0200, Adrian Hunter wrote:
>>> Some Cherry Trail boards have a dependency between the SDHCI host
>>> controller used for SD cards and an external PMIC accessed via I2C.
>>> Add a
>>>
This patch series replaces all the license text in rockchip devicetree
files text with a proper SPDX-License-Identifier.
It follows the guidelines submitted[1] by Thomas Gleixner that are not
yet merged.
These series also fixes the issue with contradicting statements in most
licenses. The introduc
Update all 32bit rockchip devicetree files to use SPDX-License-Identifiers.
All files except rk3288-veyron-analog-audio.dtsi (which is GPL 2.0 only)
claim to be GPL and X11 while the actual license text is MIT. Use the
MIT SPDX tag for them.
Signed-off-by: Klaus Goger
---
arch/arm/boot/dts/rk
Update all 64bit rockchip devicetree files to use SPDX-License-Identifiers.
All devicetrees claim to be either GPL or X11 while the actual license
text is MIT. Therefore we use MIT for the SPDX tag as X11 is clearly
wrong.
Signed-off-by: Klaus Goger
---
arch/arm64/boot/dts/rockchip/rk3328-evb.
On Thu, Dec 14, 2017 at 09:03:00PM +0100, Robert Jarzmik wrote:
> Robert Jarzmik writes:
>
> > Currently the LCD display (TD035S) on the cm-x300 platform is broken and
> > remains blank.
> ... blablabla ...
>
> Could I know when this serie can be cherry-picked please ?
Sorry. This got put on th
[Adding Rafael and Len as they, to my knowledge, also use or have a
access to a Dell XPS 13 9360. With latest Linux master do you get TPM
self-test errors, when cold starting the system without the power supply
plugged in?]
Dear Mario, dear Alexander,
the added line breaks to the quoted part
On Thu, Dec 14, 2017 at 05:30:25PM +, Mark Brown wrote:
> On Thu, Dec 14, 2017 at 05:53:57PM +0100, Olivier Moysan wrote:
>
> > + pdata->mclk1 = devm_clk_get(wm8994->dev, "MCLK1");
> > + if (IS_ERR(pdata->mclk1))
> > + pdata->mclk1 = NULL;
>
> These should special case -EPROBE_D
On Fri, Oct 13, 2017 at 09:42:48PM +0200, Robert Jarzmik wrote:
> The Toppoly panels have a global reset line. Add an optional gpio
> control for this line, for platforms which have the ability to drive it.
>
> Signed-off-by: Robert Jarzmik
> ---
> drivers/video/backlight/tdo24m.c | 3 +++
> 1 f
Hi Kishon,
Le 15/12/2017 à 06:49, Kishon Vijay Abraham I a écrit :
> Hi Cyrille,
>
> On Thursday 14 December 2017 10:33 PM, Cyrille Pitchen wrote:
>> Le 13/12/2017 à 17:50, Cyrille Pitchen a écrit :
>>> Hi Kishon,
>>>
>>> Le 05/12/2017 à 10:19, Kishon Vijay Abraham I a écrit :
Hi,
On Freitag, 15. Dezember 2017 11:32:05 CET Sven Eckelmann wrote:
> On Mittwoch, 6. Dezember 2017 11:58:14 CET Willem de Bruijn wrote:
> [...]
> > >> > ---
> > >> > MAINTAINERS| 2 +-
> > >> > include/uapi/linux/{batman_adv.h => batadv_genl.h} | 6 +++---
> >
On Thu, Dec 14, 2017 at 05:36:24PM +, Mark Brown wrote:
> On Thu, Dec 14, 2017 at 05:53:58PM +0100, Olivier Moysan wrote:
> > When defined in device tree, MCLK1 and MCLK2 are used
> > as sysclk for aif1 and aif2 interfaces respectively.
>
> That's not a valid assumption as far as I remember?
Hi,
2017-08-24 12:30 GMT+02:00 Enric Balletbo i Serra
:
> On some systems the nIRQ pin is often connect to a GPIO, then, if a given
> interrupt line is supposed to wake up the system, the corresponding input
> of that interrupt controller need to be enabled to receive signal from the
> line in que
On Fri, Oct 13, 2017 at 09:42:47PM +0200, Robert Jarzmik wrote:
> Currently the LCD display (TD035S) on the cm-x300 platform is broken and
> remains blank.
>
> The TD0245S specification requires that the chipselect is toggled
> between commands sent to the panel. This was also the purpose of the
>
Hi,
On Thu, Dec 14, 2017 at 09:01:20PM +0100, Boris Brezillon wrote:
> On Wed, 13 Dec 2017 16:57:50 -0600
> Rob Herring wrote:
> > On Wed, Dec 13, 2017 at 12:53 PM, Alexandre Belloni
> > wrote:
> > > The clocksource and clockevent timer are probed early in the boot process.
> > > At that time i
On Fri, Dec 15, 2017 at 11:25:29AM +0100, Peter Zijlstra wrote:
> The memory one is also clearly wrong, not having access does not a write
> fault make. If we have pte_write() set we should not do_wp_page() just
> because we don't have access. This falls under the "doing anything other
> than hard
On Fri, 15 Dec 2017, Chanwoo Choi wrote:
> On 2017년 12월 15일 17:20, Chanwoo Choi wrote:
> > On 2017년 12월 15일 17:14, Lee Jones wrote:
> >>> On 2017년 12월 13일 19:32, Enric Balletbo i Serra wrote:
> From: Benson Leung
>
> Extend the driver to notify host and device type cables and the p
On Thu, Dec 14, 2017 at 04:43:10PM -0600, Steven Eckhoff wrote:
> On Thu, Dec 14, 2017 at 04:36:17PM -0600, Steven Eckhoff wrote:
> > On Thu, Dec 14, 2017 at 09:32:44AM +, Charles Keepax wrote:
> >
> > > Not sure what you mean here but setting up CODEC registers
> > > directly from the machine
Hi,
On Wed, Dec 13, 2017 at 07:53:11PM +0100, Alexandre Belloni wrote:
> The clocksource and clockevent timer are probed early in the boot process.
> At that time it is difficult for linux to know whether a particular timer
> can be used as the clocksource or the clockevent or by another driver,
>
* Jarkko Nikula wrote:
> On 12/15/2017 03:28 AM, Rafael J. Wysocki wrote:
> > On Thursday, December 14, 2017 10:19:04 PM CET Andy Lutomirski wrote:
> > > __restore_processor_state() was spaghetti code, made no sense, and
> > > had bugs. And I broke resume on 32-bit systems. This series cleans
On Thu, Dec 14, 2017 at 07:08:27PM +0100, Geert Uytterhoeven wrote:
> Hi Dave,
>
> On Thu, Dec 14, 2017 at 4:24 PM, Dave P Martin wrote:
> > On Thu, Dec 14, 2017 at 02:34:50PM +, Geert Uytterhoeven wrote:
> >> On Tue, Dec 12, 2017 at 11:20 AM, Geert Uytterhoeven
> >> wrote:
> >> > During use
Actually having a scalable JSON standard format for pmu events, which allows
us to define common events per architecture / vendor and reference them per
platform JSON could be useful.
Here we're dealing with trade-off between duplication (simplicity) vs
complexity (or over-engineering).
underst
Hi Hans,
On 13-12-2017 20:49, Hans Verkuil wrote:
> On 13/12/17 15:00, Jose Abreu wrote:
>>
>> Indeed. I compared the values with the spec and they are not
>> correct. Even hsync is wrong. I already corrected in the code the
>> hsync but regarding interlace I'm not seeing an easy way to do
>> this
kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.88-rc1.gz
is missing.
same for
4.4
Am 15.12.2017 um 10:21 schrieb Greg Kroah-Hartman:
This is the start of the stable review cycle for the 3.18.88 release.
There are 64 patches in this series, all will be posted as a response
to this on
* Linus Torvalds wrote:
> On Thu, Dec 14, 2017 at 5:28 PM, Rafael J. Wysocki wrote:
> > On Thursday, December 14, 2017 10:19:04 PM CET Andy Lutomirski wrote:
> >> __restore_processor_state() was spaghetti code, made no sense, and
> >> had bugs. And I broke resume on 32-bit systems. This serie
Hi Prameela,
On Fri, 2017-12-15 at 11:13 +0530, Prameela Rani Garnepudi wrote:
> Hi Alexey,
>
> Please use the attached patch to improve TX throughput. We will be
> submitting this patch along with few others soon.
Could you please specify which branch this patch is based on?
I tried to apply
On Fri, Dec 15, 2017 at 9:59 AM, Krzysztof Kozlowski wrote:
> On Thu, Dec 14, 2017 at 5:53 PM, Mathieu Malaterre wrote:
>> Improve the DTS files by removing all the leading "0x" and zeros to fix the
>> following dtc warnings:
>>
>> Warning (unit_address_format): Node /XXX unit name should not hav
On Fri, Dec 15, 2017 at 10:33:48AM +, Marc Zyngier wrote:
> On 15/12/17 10:10, Christoffer Dall wrote:
> > On Fri, Dec 15, 2017 at 09:09:05AM +, Marc Zyngier wrote:
> >> On 15/12/17 02:27, Jia He wrote:
> >>>
> >>>
> >>
> >> [...]
> >>
> @@ -367,6 +368,7 @@ static void vtimer_save_stat
I am sorry, I still have some of these 100VGAnyLan boards somewhere in
the attic but I am unable to test.
I haven't used 100VGAnyLan for the last 20 years ! :-) - I wonder if
anybody is still using it?
Cheers
Siegfried Loeffler, DG1SEK
On 14.12.17 04:56, Jia-Ju Bai wrote:
Sorry,
I think I kn
On Fri, Dec 15, 2017 at 10:04:32 +0800,
weiping zhang wrote:
I just want to know WARN_ON WHAT in device_add_disk,
if bdi_register_owner return error code, it may fail at any step of following:
Was that output in the original boot log? I didn't see anything there
that had the string WARN_ON.
> After 2, COMPILE_TEST will work correctly.
>
> Then, Wolfram mentioned we would need to include from tmio_mmc.h
>
> https://patchwork.kernel.org/patch/10074333/
>
>
> I was waiting for a patch from him.
Yes, I am sorry. I am currently swamped with I2C work, not so much time
for SDHI. Howev
Under certain conditions EMAC stop reception of incoming packets and
continuously increment R_MISS register instead of saving data into
provided buffer. The commit implement workaround for such situation.
Then the stall detected EMAC will be restarted.
On device the stall looks like the device los
On Fri, 15 Dec 2017 08:38:30 +0100,
Sagar Arun Kamble wrote:
>
> With new interface timecounter_initialize we can initialize timecounter
> fields and underlying cyclecounter together. Update azx timecounter
> init with this new function.
>
> Signed-off-by: Sagar Arun Kamble
> Cc: Richard Cochran
701 - 800 of 1178 matches
Mail list logo
