CC: sta...@vger.kernel.org
On Fri, 2018-12-21 at 18:17 +0800, Linus Walleij wrote:
> On Thu, Dec 13, 2018 at 3:28 AM Ryder Lee wrote:
>
> > Remove prompts to make all pinctrl cores to non-visible symbols and
> > make sure the target SoCs would be coupled with the corresponding
> > cores.
> >
> >
This seems to have slipped in by accident when sorting the entries.
Fixes: ffbdd9172ee2f53020f763574b4cdad8d9760a4f
Signed-off-by: Alexander Dahl
---
Notes:
v1 -> v2:
* rebase onto v5.0-rc3 (was v4.20-rc6)
drivers/net/can/usb/Kconfig | 6 --
1 file changed, 6 deletions(-)
diff -
On 21/01/2019 18:42, Mike Rapoport wrote:
> If I understood correctly, the trouble comes from no-map range allocated in
> early_init_dt_alloc_reserved_memory_arch().
>
> There's indeed imbalance, because memblock_alloc() does kmemleak_alloc(), but
> memblock_remove() does not do kmemleak_free().
Exit latency is the time from exiting the idle state to execute
the first instruction. This place may be a typo , so fix it.
Signed-off-by: Yangtao Li
---
Documentation/admin-guide/pm/cpuidle.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/pm/cpu
The EVM consists of a system on module (SOM) and baseboard, and LCD.
This patch adds a DTSI file for the SOM and baseboard separately,
then a wrapper to combine them and specify processor type and a
LCD information.
Signed-off-by: Adam Ford
diff --git a/arch/arm/boot/dts/imx6-logicpd-baseboard.d
Hello,
syzbot has tested the proposed patch but the reproducer still triggered
crash:
possible deadlock in __do_page_fault
8021q: adding VLAN 0 to HW filter on device team0
8021q: adding VLAN 0 to HW filter on device team0
8021q: adding VLAN 0 to HW filter on device team0
8021q: adding VLAN 0
Looks like book3s/32 doesn't set RI on machine check, so
checking RI before calling die() will always be fatal
allthought this is not an issue in most cases.
Fixes: b96672dd840f ("powerpc: Machine check interrupt is a non-maskable
interrupt")
Fixes: daf00ae71dad ("powerpc/traps: restore recoverab
Em Fri, Jan 18, 2019 at 11:46:55AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Thu, Jan 17, 2019 at 08:15:19AM -0800, Song Liu escreveu:
> > This patch synthesize PERF_RECORD_KSYMBOL and PERF_RECORD_BPF_EVENT for
> > BPF programs loaded before perf-record. This is achieved by gathering
> > infor
On 22/01/2019 15:02, Marc Gonzalez wrote:
> On 21/01/2019 18:42, Mike Rapoport wrote:
>
>> If I understood correctly, the trouble comes from no-map range allocated in
>> early_init_dt_alloc_reserved_memory_arch().
>>
>> There's indeed imbalance, because memblock_alloc() does kmemleak_alloc(), bu
On Tue, Jan 08, 2019 at 10:21:25AM -0800, Florian Fainelli wrote:
On 1/7/19 9:01 PM, Florian Fainelli wrote:
Le 12/4/18 à 4:04 PM, Ivan Khoronzhuk a écrit :
On Tue, Dec 04, 2018 at 11:49:27AM -0800, Florian Fainelli wrote:
...
I was thinking also about pinned list of vlans to the address, b
From: Colin Ian King
A return statement is indented incorrectly, fix this.
Signed-off-by: Colin Ian King
---
drivers/staging/rtl8723bs/core/rtw_xmit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_xmit.c
b/drivers/staging/rtl8723bs/core
commit d6abe6df706c66d803e6dd4fe98c1b6b7f125a56 (drm/bridge:
sil_sii8620: do not have a dependency of RC_CORE) added a dependency on
INPUT. However, this causes problems with other drivers, in particular
an input driver that depends on MFD_INTEL_LPSS_PCI (to be added in a
future commit):
drivers
On Fri, Dec 28, 2018 at 01:50:53PM +0100, Hannes Reinecke wrote:
> On 12/21/18 4:29 PM, James Bottomley wrote:
> > [scsi list cc added]
> > On Fri, 2018-12-21 at 08:54 +0100, Greg Kroah-Hartman wrote:
> > > We are trying to get rid of BUS_ATTR() and the usage of that in the
> > > fcoe driver can be
On Tue, 22 Jan 2019 at 14:52, Geert Uytterhoeven wrote:
>
> Hi Heiner,
>
> On Fri, Jan 18, 2019 at 9:58 PM Heiner Kallweit wrote:
> > On 18.01.2019 09:48, Krzysztof Kozlowski wrote:
> > > On Fri, 18 Jan 2019 at 09:39, Krzysztof Kozlowski wrote:
> > >> On today's next (next-20190118) my Colibri V
Initializing accounting_timestamp to something different from 0 during
pm_runtime_init() doesn't make sense and put useless ordering constraint between
timekeeping_init() and pm_runtime_init().
PM runtime should start accounting time only when it is enable and discard
the period when disabled.
Set
Move pm_runtime accounted time to raw nsec. The subject of the patchset
has changed as the 1st patch of the previous versions has been queued by
Rafael.
Patch 1 set accounting_timestamp to 0 in pm_runtime_init and update it when
enable. So
we remove ordering constraint between timekeeping_init an
From: Thara Gopinath
This patch replaces jiffies based accounting for runtime_active_time
and runtime_suspended_time with ktime-based accounting. This makes the
runtime debug counters inline with genpd and other PM subsytems which
use ktime-based accounting.
Timekeeping is initialized before dri
Hello,
syzbot has tested the proposed patch and the reproducer did not trigger
crash:
Reported-and-tested-by:
syzbot+148c2885d71194f18...@syzkaller.appspotmail.com
Tested on:
commit: 48b161983ae5 Merge tag 'xarray-5.0-rc3' of git://git.infra..
git tree: upstream
kernel conf
On 22-Jan 13:29, Quentin Perret wrote:
> On Tuesday 22 Jan 2019 at 12:45:46 (+), Patrick Bellasi wrote:
> > On 22-Jan 12:13, Quentin Perret wrote:
> > > On Tuesday 15 Jan 2019 at 10:15:08 (+), Patrick Bellasi wrote:
> > > > The Energy Aware Scheduler (AES) estimates the energy impact of wak
From: Colin Ian King
There are a bunch of various indentation issues, clean these up.
Signed-off-by: Colin Ian King
---
drivers/usb/gadget/function/f_uac1.c | 8 ++---
drivers/usb/gadget/legacy/inode.c| 40
drivers/usb/gadget/udc/aspeed-vhub/hub.c | 2 +-
On Tue, 22 Jan 2019 at 15:24, Vincent Guittot
wrote:
>
> From: Thara Gopinath
>
> This patch replaces jiffies based accounting for runtime_active_time
> and runtime_suspended_time with ktime-based accounting. This makes the
> runtime debug counters inline with genpd and other PM subsytems which
>
We are trying to get rid of BUS_ATTR() and the usage of that in the fcoe
driver can be trivially converted to use BUS_ATTR_WO(), so use that
instead.
Cc: Johannes Thumshirn
Cc: "James E.J. Bottomley"
Cc: "Martin K. Petersen"
Signed-off-by: Greg Kroah-Hartman
---
v2: Made simpler with wrapper f
There's no need to export fcoe_ctlr_destroy_store as a symbol, so remove
the EXPORT_SYMBOL() line for it.
Cc: Johannes Thumshirn
Cc: "James E.J. Bottomley"
Cc: "Martin K. Petersen"
Signed-off-by: Greg Kroah-Hartman
---
drivers/scsi/fcoe/fcoe_transport.c | 1 -
1 file changed, 1 deletion(-)
d
I have a mission worth $ 11,000,000.00 from you
Hello Dan,
Am 22.01.19 um 14:37 schrieb Dan Murphy:
> Wolfgang
>
> On 1/22/19 3:35 AM, Wolfgang Grandegger wrote:
>> Hello,
>>
>> Am 17.01.19 um 21:05 schrieb Dan Murphy:
>>> Migrate the m_can code to use the m_can_platform framework
>>> code.
>>>
>>> Signed-off-by: Dan Murphy
>>> ---
>>> drive
Hi Min,
On Tue, Jan 22, 2019 at 05:36:13PM +0800, Min Guo wrote:
> Hi Bin,
>
> Sorry to bother you again, I encounter a problem about the extcon
> property.
>
> I don't find a common driver describing the usb-connector. Is
> there any driver that I can refer to, specially the way to switch MUSB
Kees Cook writes:
> On Tue, Jan 22, 2019 at 8:15 AM Greg KH wrote:
>>
>> On Mon, Jan 21, 2019 at 10:36:18AM -0800, Andi Kleen wrote:
>> > > + /* Check the start address: needs to be page-aligned.. */
>> > > +- if (start & ~PAGE_MASK)
>> > > ++ if (start & ~PAGE_MASK) {
>> > > ++
>> > > ++
When calling debugfs code, there is no need to ever check the return
value of the call, as no logic should ever change if a call works
properly or not. Fix up a bunch of x86-specific code to not care about
the results of debugfs.
Greg Kroah-Hartman (6):
x86: mce: no need to check return value o
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc:
Cc: Tony Luck
Cc: Vishal Verm
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Dave Hansen
Cc: Andy Lutomirski
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvi
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc:
Signed-off-by: Greg Kroah-Hart
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc:
Signed-off-by: Greg Kroah-Hart
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav P
From: Colin Ian King
Two statements are incorrecly indented, fix these by removing a space.
Signed-off-by: Colin Ian King
---
drivers/net/ethernet/amd/amd8111e.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/amd/amd8111e.c
b/drivers/net/ethernet/
Hi Robin/Lorenzo,
A gentle reminder on this series. Please take a look.
Thanks,
Shameer
> -Original Message-
> From: Linuxarm [mailto:linuxarm-boun...@huawei.com] On Behalf Of Shameer
> Kolothum
> Sent: 30 November 2018 15:48
> To: lorenzo.pieral...@arm.com; robin.mur...@arm.com
> Cc: ma
Em Tue, Jan 22, 2019 at 12:13:20PM -0200, Arnaldo Carvalho de Melo escreveu:
> Em Fri, Jan 18, 2019 at 11:46:55AM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Thu, Jan 17, 2019 at 08:15:19AM -0800, Song Liu escreveu:
> > > This patch synthesize PERF_RECORD_KSYMBOL and PERF_RECORD_BPF_EVENT for
On Tuesday 22 Jan 2019 at 14:26:06 (+), Patrick Bellasi wrote:
> On 22-Jan 13:29, Quentin Perret wrote:
> > On Tuesday 22 Jan 2019 at 12:45:46 (+), Patrick Bellasi wrote:
> > > On 22-Jan 12:13, Quentin Perret wrote:
> > > > On Tuesday 15 Jan 2019 at 10:15:08 (+), Patrick Bellasi wrote:
Noise, I am wrong...
On 1/22/19, Borislav Petkov wrote:
> On Mon, Jan 21, 2019 at 11:19:58PM +, Sinan Kaya wrote:
>> After 'commit 5d32a66541c4 ("PCI/ACPI: Allow ACPI to be built without
>> CONFIG_PCI set")' dependencies on CONFIG_PCI that previously were
>> satisfied implicitly through dependencies on CONFIG_ACPI
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Marc Zyngier
Cc: Peng Donglin
Cc:
Signed-off-by: Greg Kroah-Hartman
--
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Paul Walmsley
Cc: Aaro Koskinen
Cc: Tony Lindgren
Cc: Russell King
Cc: Kevin Hilman
Cc: linux-o...@vger.ker
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Russell King
Cc: Jinbum Park
Cc: Kees Cook
Cc: Laura Abbott
Cc: linux-arm-ker...@lists.infradead.org
Signed-
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Kevin Hilman
Cc: Tony Lindgren
Cc: Russell King
Cc: linux-o...@vger.kernel.org
Cc: linux-arm-ker...@lists.inf
When calling debugfs code, there is no need to ever check the return
value of the call, as no logic should ever change if a call works
properly or not. Fix up a bunch of x86-specific code to not care about
the results of debugfs
Greg Kroah-Hartman (4):
arm64: dump: no need to check return value
Hello,
On 22/01/2019 02:05, Zhang, Lei wrote:
> Mark Rutland wrote:
>> * How often does this fault occur?
> In my test, this fault occurs once every several times
> in the OS boot sequence, and after the completion of OS boot,
> this fault have never occurred.
> In my opinion, this fault rarely oc
On 22-Jan 14:56, Peter Zijlstra wrote:
> On Tue, Jan 15, 2019 at 10:15:04AM +, Patrick Bellasi wrote:
>
> > diff --git a/include/linux/sched.h b/include/linux/sched.h
> > index 84294925d006..c8f391d1cdc5 100644
> > --- a/include/linux/sched.h
> > +++ b/include/linux/sched.h
> > @@ -625,6 +625,
On 1/22/19 14:42, Greg KH wrote:
> On Wed, Jan 16, 2019 at 06:10:55PM +0200, Georgi Djakov wrote:
[..]
>
> All now queued up, thanks.
>
> greg k-h
Hi Greg,
Thanks for considering these patches! Actually i have a branch named
icc-next [1] which is pulled into linux-next. I will drop these same
p
Hello,
syzbot has tested the proposed patch and the reproducer did not trigger
crash:
Reported-and-tested-by:
syzbot+4b8b031b89e6b96c4...@syzkaller.appspotmail.com
Tested on:
commit: 48b161983ae5 Merge tag 'xarray-5.0-rc3' of git://git.infra..
git tree: upstream
kernel conf
Hello Dan,
Am 22.01.19 um 14:04 schrieb Dan Murphy:
> Wolfgang
>
> Thanks for the review
>
> On 1/22/19 2:16 AM, Wolfgang Grandegger wrote:
>> Hello Dan,
>>
>> looks already quite good...
>>
>> Am 17.01.19 um 21:05 schrieb Dan Murphy:
>>> Create a m_can platform framework that peripherial
>>> de
On 01/22/19 11:02, Tomasz Figa wrote:
> On Mon, Nov 12, 2018 at 8:37 PM Hans Verkuil wrote:
>>
>> Hi Tomasz,
>>
>> A general note for the stateful and stateless patches: they describe specific
>> use-cases of the more generic Codec Interface, and as such should be one
>> level deeper in the sectio
Quoting Joerg Roedel (2019-01-22 13:01:09)
> Hi Daniel,
>
> On Tue, Jan 22, 2019 at 11:46:39AM +0100, Daniel Vetter wrote:
> > Note that the string of platforms which have various issues with iommu
> > and igfx is very long, thus far we only disabled it where there's no
> > workaround to stop it f
On 1/22/19 1:47 AM, Matti Vaittinen wrote:
Support RTC block in ROHM bd70528 power management IC. Support
getting and setting the time and date as well as arming an alarm
which can also be used to wake the PMIC from standby state.
HW supports wake interrupt only for the next 24 hours (sec, minut
Em Tue, Jan 22, 2019 at 12:31:17PM -0200, Arnaldo Carvalho de Melo escreveu:
> Em Tue, Jan 22, 2019 at 12:13:20PM -0200, Arnaldo Carvalho de Melo escreveu:
> > Em Fri, Jan 18, 2019 at 11:46:55AM -0300, Arnaldo Carvalho de Melo escreveu:
> > > Em Thu, Jan 17, 2019 at 08:15:19AM -0800, Song Liu escre
From: wangbo
In uio_dmem_genirq_open the variable ret is unneeded,remove it now.
Signed-off-by: Bo Wang
---
drivers/uio/uio_dmem_genirq.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/uio/uio_dmem_genirq.c b/drivers/uio/uio_dmem_genirq.c
index 003bada..2be7569 1
On 1/22/19 1:44 AM, Matti Vaittinen wrote:
ROHM BD70528MWV is an ultra-low quiescent current general
purpose single-chip power management IC for battery-powered
portable devices.
Add MFD core which enables chip access for following subdevices:
- regulators/LED drivers
- battery-c
On Tue, Jan 22, 2019 at 12:31:17PM -0200, Arnaldo Carvalho de Melo wrote:
> Em Tue, Jan 22, 2019 at 12:13:20PM -0200, Arnaldo Carvalho de Melo escreveu:
> > Em Fri, Jan 18, 2019 at 11:46:55AM -0300, Arnaldo Carvalho de Melo escreveu:
> > > Em Thu, Jan 17, 2019 at 08:15:19AM -0800, Song Liu escreveu
Web de correo electrónico de administración de notificaciones
Este mensaje es de nuestro centro de mensajería Web Admin a todos nuestros
propietarios de cuentas de correo electrónico. Estamos eliminando el acceso a
todos nuestros clientes de correo web. Su cuenta de correo electrónico se
actual
On 22.01.2019 14:21, Philippe Schenker wrote:
> From: Philippe Schenker
>
> Add the stmpe-adc DT node as found on Toradex iMX6 modules
>
> Signed-off-by: Philippe Schenker
Reviewed-by: Stefan Agner
> ---
>
> arch/arm/boot/dts/imx6qdl-apalis.dtsi | 22 ++
> arch/arm/boo
On 22.01.2019 14:21, Philippe Schenker wrote:
> From: Philippe Schenker
>
> Add the stmpe-adc DT node as found on Toradex T30 modules
>
> Signed-off-by: Philippe Schenker
Reviewed-by: Stefan Agner
>
> ---
>
> arch/arm/boot/dts/tegra30-apalis-v1.1.dtsi | 22 ++
> arch/a
$ 1,000,000.00 dollaria on lahjoittanut sinulle Maureen David Kaltschmidt, joka
voitti 758,7 miljoonan dollarin Powerball Jackpotin. Ota yhteyttä
sähköpostitse: maureendavidkaltschmidt...@gmail.com saadaksesi lisätietoja
Hi Will,
On Tue, Jan 22, 2019 at 05:44:02AM +, Will Deacon wrote:
> On Mon, Jan 21, 2019 at 02:21:28PM +, Catalin Marinas wrote:
> > On Sat, Jan 19, 2019 at 11:58:27PM +, Will Deacon wrote:
> > > On Thu, Jan 17, 2019 at 07:42:44AM +, chenwandun wrote:
> > > > Recently, I do some te
Hi Nick,
Missatge de Nick Crews del dia ds., 19 de gen.
2019 a les 1:17:
>
> From: Duncan Laurie
>
> This Embedded Controller has an internal RTC that is exposed
> as a standard RTC class driver with read/write functionality.
>
> The driver is added to the drivers/rtc/ so that the maintainer of
On Tue, Jan 22, 2019 at 02:01:15PM +, Patrick Bellasi wrote:
> On 22-Jan 14:28, Peter Zijlstra wrote:
> > On Tue, Jan 22, 2019 at 10:43:05AM +, Patrick Bellasi wrote:
> > > On 22-Jan 10:37, Peter Zijlstra wrote:
> >
> > > > Sure, I get that. What I don't get is why you're adding that (2) h
Em Tue, Jan 22, 2019 at 03:51:19PM +0100, Jiri Olsa escreveu:
> On Tue, Jan 22, 2019 at 12:31:17PM -0200, Arnaldo Carvalho de Melo wrote:
> > Em Tue, Jan 22, 2019 at 12:13:20PM -0200, Arnaldo Carvalho de Melo escreveu:
> > > Em Fri, Jan 18, 2019 at 11:46:55AM -0300, Arnaldo Carvalho de Melo
> > >
When calling debugfs code, there is no need to ever check the return
value of the call, as no logic should ever change if a call works
properly or not. Fix up a bunch of x86-specific code to not care about
the results of debugfs.
Greg Kroah-Hartman (5):
mips: cavium: no need to check return val
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Ralf Baechle
Cc: Paul Burton
Cc: James Hogan
Cc: Yangtao Li
Cc: linux-m...@vger.kernel.org
Signed-off-by: Gr
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Ralf Baechle
Cc: Paul Burton
Cc: James Hogan
Cc: linux-m...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Ralf Baechle
Cc: Paul Burton
Cc: James Hogan
Cc: Yangtao Li
Cc: Andrew Morton
Cc: Mike Rapoport
Cc: Mathie
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Ralf Baechle
Cc: Paul Burton
Cc: James Hogan
Cc: Andy Shevchenko
Cc: linux-m...@vger.kernel.org
Signed-off-b
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: John Crispin
Cc: Ralf Baechle
Cc: Paul Burton
Cc: James Hogan
Cc: linux-m...@vger.kernel.org
Signed-off-by:
On Tue, Jan 22, 2019 at 04:45:20PM +0200, Georgi Djakov wrote:
> On 1/22/19 14:42, Greg KH wrote:
> > On Wed, Jan 16, 2019 at 06:10:55PM +0200, Georgi Djakov wrote:
> [..]
> >
> > All now queued up, thanks.
> >
> > greg k-h
>
> Hi Greg,
>
> Thanks for considering these patches! Actually i have
On 22-Jan 14:39, Quentin Perret wrote:
> On Tuesday 22 Jan 2019 at 14:26:06 (+), Patrick Bellasi wrote:
> > On 22-Jan 13:29, Quentin Perret wrote:
> > > On Tuesday 22 Jan 2019 at 12:45:46 (+), Patrick Bellasi wrote:
> > > > On 22-Jan 12:13, Quentin Perret wrote:
> > > > > On Tuesday 15 Jan
Hi Nick,
I'd like to have some feedback from input subsystem if it's possible,
so adding linux-in...@vger.kernel.org and Dmitry. Don't forget to add
them for the next versions.
Missatge de Nick Crews del dia ds., 19 de gen.
2019 a les 1:16:
>
> From: Duncan Laurie
>
> The Wilco Embedded Control
Hi Suzuki,
Thanks for looking into this. Please find my response inline.
On 1/22/2019 7:30 PM, Suzuki K Poulose wrote:
Hi Sai,
On 01/22/2019 01:37 PM, Sai Prakash Ranjan wrote:
Add coresight components found on Qualcomm SDM845 SoC.
Signed-off-by: Sai Prakash Ranjan
Sorry, but I hadn't no
Hi Nick,
I'd like to have some feedback from power-supply subsystem if it's possible,
so adding Sebastian. Don't forget to add him for the next versions.
Missatge de Nick Crews del dia ds., 19 de gen.
2019 a les 1:15:
>
> From: Nick Crews
>
> Create "peakshift" and "advanced_battery_charging" d
Hi Souptick,
On 2019-01-11 16:11, Souptick Joarder wrote:
> Convert to use vm_insert_range_buggy to map range of kernel memory
> to user vma.
>
> This driver has ignored vm_pgoff. We could later "fix" these drivers
> to behave according to the normal vm_pgoff offsetting simply by
> removing the _b
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Anil Gurumurthy
Cc: Sudarsana Kalluru
Cc: "James E.J. Bottomley"
Cc: "Martin K. Petersen"
Cc: linux-s...@vge
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Karan Tilak Kumar
Cc: Sesidhar Baddela
Cc: "James E.J. Bottomley"
Cc: "Martin K. Petersen"
Cc: linux-s...@vg
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Satish Kharat
Cc: Sesidhar Baddela
Cc: Karan Tilak Kumar
Cc: "James E.J. Bottomley"
Cc: "Martin K. Petersen"
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: qlogic-storage-upstr...@cavium.com
Cc: "James E.J. Bottomley"
Cc: "Martin K. Petersen"
Cc: linux-s...@vger.ker
From: QiaoChong
git blame drivers/parport/parport_pc.c
181bf1e815a2a (Alan Cox 2009-06-11 13:08:10 +0100 1376) static
struct superio_struct *find_superio(struct parport *p)
^1da177e4c3f4 (Linus Torvalds2005-04-16 15:20:36 -0700 1377) {
181bf1e815a2a (Alan Cox
When calling debugfs code, there is no need to ever check the return
value of the call, as no logic should ever change if a call works
properly or not. Fix up a bunch of x86-specific code to not care about
the results of debugfs.
Greg Kroah-Hartman (7):
scsi: bfa: no need to check return value
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: qla2xxx-upstr...@qlogic.com
Cc: "James E.J. Bottomley"
Cc: "Martin K. Petersen"
Cc: linux-s...@vger.kernel.org
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: James Smart
Cc: Dick Kennedy
Cc: "James E.J. Bottomley"
Cc: "Martin K. Petersen"
Cc: linux-s...@vger.kernel.
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: "James E.J. Bottomley"
Cc: "Martin K. Petersen"
Cc: Varun Prakash
Cc: Bjorn Helgaas
Cc: Johannes Thumshirn
From: Colin Ian King
Clean up { brace to fix cppcheck warning. Remove some trailing spaces
at end of a statement. Also clean up an indentation issue.
Signed-off-by: Colin Ian King
---
drivers/scsi/atp870u.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/scs
After the previous patch we see, that whole files are ifdeffed depending
on CONFIG options. So do not build the files at all if the CONFIG is not
enabled. (I.e. move the check from .c to Makefile.)
Signed-off-by: Jiri Slaby
---
drivers/usb/misc/sisusbvga/Makefile | 3 ++-
drivers/usb/misc/s
Convert SISUSB_VADDR and SISUSB_HADDR to inline functions. Now, there
are no more hidden accesses to local variables (vc_data and
sisusb_usb_data).
sisusb_haddr returns unsigned long from now on, not u16 *, as ulong is
what every caller expects -- we can remove some casts.
Call sites were aligned
Remove macros which are only wrappers around standard operations. When
we expand them into code, we see that sisusbcon_memsetw can simply use
memset16 and sisusbcon_putcs can just call memcpy. So make the code
compact.
Signed-off-by: Jiri Slaby
---
drivers/usb/misc/sisusbvga/sisusb_con.c | 48 ++
Philipp,
On Mon, Jan 21, 2019 at 12:49:10PM +0100, Philipp Zabel wrote:
> Hi,
>
> On Fri, 2019-01-18 at 17:04 -0800, Steve Longerbeam wrote:
> > Disable the SMFC before disabling the IDMA channel, instead of after,
> > in csi_idmac_unsetup().
> >
> > This fixes a complete system hard lockup on t
On Tuesday 22 Jan 2019 at 15:01:37 (+), Patrick Bellasi wrote:
> > I'm not saying it's useful, I'm saying userspace can decide to do that
> > if it thinks it is a good idea. The default should be min_cap = 1024 for
> > RT, no questions. But you _can_ change it at runtime if you want to.
> > Tha
On Tue, Jan 22, 2019 at 3:24 PM Vincent Guittot
wrote:
>
> Initializing accounting_timestamp to something different from 0 during
> pm_runtime_init() doesn't make sense and put useless ordering constraint
> between
> timekeeping_init() and pm_runtime_init().
> PM runtime should start accounting t
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Giovanni Cabiddu
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: Conor McLoughlin
Cc: Waiman Long
Cc: qat-li...@in
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: Robert Richter
Cc: Jan Glauber
Cc: linux-cry...@vger.kernel.org
Signed-
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: "Horia Geantă"
Cc: Aymen Sghaier
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: linux-cry...@vger.kernel.org
Signe
There are two macros defined:
1) ifdef CONFIG_COMPAT => define SISUSB_NEW_CONFIG_COMPAT
2) ifdef CONFIG_USB_SISUSBVGA_CON => define INCL_SISUSB_CON
Remove the latter and make use only of the former. This removes one
layer of obfuscation.
Signed-off-by: Jiri Slaby
---
drivers/usb/misc/sisusbvga/
On Tue, Jan 22, 2019 at 02:43:29PM +, Patrick Bellasi wrote:
> On 22-Jan 14:56, Peter Zijlstra wrote:
> > On Tue, Jan 15, 2019 at 10:15:04AM +, Patrick Bellasi wrote:
> >
> > > diff --git a/include/linux/sched.h b/include/linux/sched.h
> > > index 84294925d006..c8f391d1cdc5 100644
> > > --
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Tom Lendacky
Cc: Gary Hook
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: linux-cry...@vger.kernel.org
Signed-off-
When calling debugfs code, there is no need to ever check the return
value of the call, as no logic should ever change if a call works
properly or not. Fix up a bunch of crypto-specific code to not care
about the results of debugfs.
Greg Kroah-Hartman (7):
crypto: qat: no need to check return v
401 - 500 of 1233 matches
Mail list logo
