On Tue, 8 Jan 2019 11:26:30 +0100
Eric Auger wrote:
> This patch adds a new 64kB region aiming to report nested mode
> translation faults.
>
> The region contains a header with the size of the queue,
> the producer and consumer indices and then the actual
> fault queue data. The producer is
Quoting Manivannan Sadhasivam (2018-12-31 10:55:12)
> S500 SoC requires configurable delay for different PLLs. Hence, add
> a separate macro for declaring a PLL with configurable delay and also
> modify the existing OWL_PLL_NO_PARENT macro to use default delay so
> that no need to modify the
On Fri, Jan 11, 2019 at 08:37:12PM +0530, Balakrishna Godavarthi wrote:
> Hi Matthias,
>
> On 2019-01-11 07:07, Matthias Kaehlcke wrote:
> > On Thu, Jan 10, 2019 at 08:22:12PM +0530, Balakrishna Godavarthi wrote:
> > > Hi Johan,
> > >
> > > On 2019-01-10 20:09, Johan Hovold wrote:
> > > > On
The QMX86 is a PLD present on some TQ-Systems ComExpress modules. It
provides 1 or 2 I2C bus masters, 8 GPIOs and a watchdog timer. Add an
MFD which will instantiate the individual drivers.
Signed-off-by: Andrew Lunn
---
v2:
Drop setting i2c bus speed, which removes the build dependencies on
Quoting Manivannan Sadhasivam (2018-12-31 10:55:16)
> diff --git a/drivers/clk/actions/owl-s500.c b/drivers/clk/actions/owl-s500.c
> new file mode 100644
> index ..93feea8d71e2
> --- /dev/null
> +++ b/drivers/clk/actions/owl-s500.c
> @@ -0,0 +1,524 @@
> +// SPDX-License-Identifier:
zzoru writes:
>> I received 3 spam messages from this address today.
>> We can simply ignore this report.
> I already mentioned about this.
>
>> and, sorry for my encrypted mails.
>> I don't understand this failure report at all.
>>
>> I don't see the connection to copy_net_ns(). And I don't
On 1/11/19 2:58 PM, Qian Cai wrote:
A GPF was reported,
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: [#1] SMP KASAN
kasan_die_handler.cold.22+0x11/0x31
notifier_call_chain+0x17b/0x390
Quoting Brian Masney (2019-01-11 15:00:04)
> On Fri, Jan 11, 2019 at 02:07:09PM -0800, Stephen Boyd wrote:
> > Quoting Brian Masney (2019-01-09 17:12:54)
> > > Convert the spmi-pmic-arb IRQ code to use the version 2 IRQ interface
> > > in order to support hierarchical IRQ chips. This is necessary
On Fri, Jan 11, 2019 at 08:02:00PM +0530, Balakrishna Godavarthi wrote:
> On 2019-01-11 06:25, Matthias Kaehlcke wrote:
> > On Thu, Jan 10, 2019 at 08:18:37PM +0530, Balakrishna Godavarthi wrote:
> > > Hi Johan,
> > >
> > > On 2019-01-09 20:08, Johan Hovold wrote:
> > > > On Fri, Dec 21, 2018 at
On Fri, Jan 11 2019 at 15:55 -0700, Stephen Boyd wrote:
Quoting Lina Iyer (2019-01-07 10:48:36)
On Thu, Dec 20 2018 at 13:19 -0700, Stephen Boyd wrote:
>Quoting Lina Iyer (2018-12-19 14:11:01)
>> +static const struct pdc_gpio_pin_data sdm845_gpio_data = {
>> + .size =
Hi,
On Fri, Jan 11, 2019 at 2:54 PM Bjorn Andersson
wrote:
>
> On Qualcomm SDM845 the capabilities of the UFS MEM controller states
> that it's capable of dealing with 64 bit addresses, but DMA addresses
> are truncated causing IOMMU faults when trying to issue operations.
>
> Limit the DMA mask
CONFIG_SCSI_UFS_QCOM selects CONFIG_PHY_QCOM_UFS, assuming that
this was the only possible PHY driver Qualcomm's UFS controller
would use. But in SDM845, the UFS driver is bundled into phy-qcom-qmp,
and phy-qcom-ufs is unused.
Remove the select, since for SDM845 it adds useless drivers to the
On 1/11/19 1:55 PM, Kirill A. Shutemov wrote:
> On Fri, Jan 11, 2019 at 08:10:03PM +, Mike Kravetz wrote:
>> At LPC last year, Boaz Harrosh asked why he had to 'jump through hoops'
>> to get an address returned by mmap() suitably aligned for THP. It seems
>> that if mmap is asking for a
On 1/11/19 2:06 PM, Andy Lutomirski wrote:
> On Fri, Jan 11, 2019 at 12:42 PM Dave Hansen wrote:
>>
The second process could easily have the page's old TLB entry. It could
abuse that entry as long as that CPU doesn't context switch
(switch_mm_irqs_off()) or otherwise flush the TLB
On 1/11/19 1:42 PM, Dave Hansen wrote:
>>> The second process could easily have the page's old TLB entry. It could
>>> abuse that entry as long as that CPU doesn't context switch
>>> (switch_mm_irqs_off()) or otherwise flush the TLB entry.
>>
>> That is an interesting scenario. Working through
On Fri, 11 Jan 2019 16:02:44 -0700
Alex Williamson wrote:
> On Tue, 8 Jan 2019 11:26:18 +0100
> Eric Auger wrote:
>
> > This patch adds the VFIO_IOMMU_BIND_MSI ioctl which aims at
> > passing the guest MSI binding to the host.
> >
> > Signed-off-by: Eric Auger
> >
> > ---
> >
> > v2 ->
Quoting Rob Herring (2019-01-09 11:36:56)
>
> > >However, my main concern is documenting something genericish in a
> > >device specific binding. It looks like Tegra is trying to add the same
> > >thing, so this needs to be documented in a common place. One question
> > >is whether wakeup is the
>>
>>>> HEAD commit: b808822a75a3 Add linux-next specific files for 20190111
>>>> git tree: linux-next
>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=179c22f740
>>>> kernel config: https://syzkaller.appspot.com/x/
On Fri, Jan 11, 2019 at 02:58:26PM +0200, Jarkko Sakkinen wrote:
> On Wed, Jan 09, 2019 at 08:31:37AM -0800, Sean Christopherson wrote:
> > On Tue, Jan 08, 2019 at 02:54:11PM -0800, Andy Lutomirski wrote:
> > > On Tue, Jan 8, 2019 at 2:09 PM Sean Christopherson
> > > wrote:
> > > >
> > > >
On Thu, Jan 10, 2019 at 10:39 PM Richard Guy Briggs wrote:
> On 2019-01-10 20:12, Paul Moore wrote:
> > On Thu, Jan 10, 2019 at 5:59 PM Richard Guy Briggs wrote:
> > > On 2019-01-03 15:11, Paul Moore wrote:
> > > > On Wed, Oct 31, 2018 at 5:17 PM Richard Guy Briggs
> > > > wrote:
> > > > > On
On Fri, Jan 11, 2019 at 03:58:43PM -0500, Qian Cai wrote:
> diff --git a/lib/rbtree_test.c b/lib/rbtree_test.c
> index b7055b2a07d3..afad0213a117 100644
> --- a/lib/rbtree_test.c
> +++ b/lib/rbtree_test.c
> @@ -345,6 +345,17 @@ static int __init rbtree_test_init(void)
> check(0);
>
On Fri, Jan 11, 2019 at 07:53:43PM +0530, Balakrishna Godavarthi wrote:
> Hi Matthias,
>
> On 2019-01-11 02:13, Matthias Kaehlcke wrote:
> > Hi Balakrishna,
> >
> > On Thu, Jan 10, 2019 at 08:30:43PM +0530, Balakrishna Godavarthi wrote:
> > > Hi Matthias,
> > >
> > > On 2019-01-03 03:45,
On Fri, Jan 11, 2019 at 4:42 PM Stephen Boyd wrote:
>
> Quoting Rob Herring (2019-01-11 12:49:04)
> > On Fri, Jan 11, 2019 at 12:54 PM Stephen Boyd wrote:
> > >
> > > Quoting Rob Herring (2019-01-11 10:27:48)
> > > > On Fri, Jan 11, 2019 at 11:44 AM Stephen Boyd wrote:
> > > > >
> > > > > Any
Hi Linus,
Dave sends out his pull, everybody remembers holidays are over :-)
Since Dave's already in w/e mode and it was quite a few patches I figured
better to apply all the pulls and forward them to you. Hence here 2nd part
of bugfixes for -rc2.
nouveau:
one backlight, falcon register access,
Request the newly minted reset controller from the Qualcomm UFS
controller, and use it to toggle the PHY reset line from within
the PHY. This will allow us to merge the two phases of UFS PHY
initialization.
Signed-off-by: Evan Green
---
Note: this change is dependent on the previous changes,
On Tue, 8 Jan 2019 11:26:18 +0100
Eric Auger wrote:
> This patch adds the VFIO_IOMMU_BIND_MSI ioctl which aims at
> passing the guest MSI binding to the host.
>
> Signed-off-by: Eric Auger
>
> ---
>
> v2 -> v3:
> - adapt to new proto of bind_guest_msi
> - directly use
The phy code was using implicit sequencing between the PHY driver
and the UFS driver to implement certain hardware requirements.
Specifically, the PHY reset register in the UFS controller needs
to be deasserted before serdes start occurs in the PHY.
Before this change, the code was doing this by
On Thu, Jan 10, 2019 at 07:24:01PM +0800, Tan Hu wrote:
> @@ -12,13 +12,13 @@ static int show_softirqs(struct seq_file *p, void *v)
> int i, j;
>
> seq_puts(p, "");
> - for_each_possible_cpu(i)
> + for_each_online_cpu(i)
> seq_printf(p,
Add the reset controller for the UFS controller, and wire it up
so that the UFS PHY can initialize itself without relying on
implicit sequencing between the two drivers.
Signed-off-by: Evan Green
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Wire up the reset controller in the Qcom UFS controller for the PHY.
This will be used to toggle PHY reset during initialization of the PHY.
Signed-off-by: Evan Green
---
This commit is based atop the series at [1]. Patches 1 and 2 of that
series have landed, but 3, 4, and 5 are still
Add a resets property to the PHY that represents the PHY reset
register in the UFS controller itself. This better describes the
complete specification of the PHY, and allows the PHY to perform
its initialization in a single function, rather than relying on
back-channel sequencing of initialization
For UFS, move the actual firing up of the PHY to phy_poweron and
phy_poweroff callbacks, rather than init/exit. UFS calls
phy_poweroff during suspend, so now all clocks and regulators for
the phy can be powered down during suspend.
Signed-off-by: Evan Green
---
Expose a reset controller that the phy can use to perform its
initialization in a single callback.
Also, change the use of the phy functions from ufs-qcom such that
phy_poweron actually fires up the phy, and phy_poweroff actually
powers it down.
Signed-off-by: Evan Green
---
Note: This change
Add a required reset to the SDM845 UFS phy to express the PHY reset
bit inside the UFS controller register space. Before this change, this
reset was not expressed in the DT, and the driver utilized two different
callbacks (phy_init and phy_poweron) to implement a two-phase
initialization procedure
The goal with this series is to enable shutting off regulators that power
UFS during system suspend.
In "the good life" version of this, we'd just disable the regulators
in phy_poweroff and be done with it. Unfortunately, that's not symmetric,
as regulators are not enabled during phy_poweron. Ok,
On Fri, Jan 11, 2019 at 02:07:09PM -0800, Stephen Boyd wrote:
> Quoting Brian Masney (2019-01-09 17:12:54)
> > Convert the spmi-pmic-arb IRQ code to use the version 2 IRQ interface
> > in order to support hierarchical IRQ chips. This is necessary so that
> > spmi-gpio can be setup as a
Hi arm-soc maintainers,
This is an updated pull request to replace one problematic patch
regarding to guts driver. Please ignore the last pull request.
The following changes since commit bfeffd155283772bbe78c6a05dec7c0128ee500c:
Linux 5.0-rc1 (2019-01-06 17:08:20 -0800)
are available in
Quoting Lina Iyer (2019-01-07 10:48:36)
> On Thu, Dec 20 2018 at 13:19 -0700, Stephen Boyd wrote:
> >Quoting Lina Iyer (2018-12-19 14:11:01)
>
> >> +static const struct pdc_gpio_pin_data sdm845_gpio_data = {
> >> + .size = ARRAY_SIZE(sdm845_gpio_pdc_map),
> >> + .map =
On Qualcomm SDM845 the capabilities of the UFS MEM controller states
that it's capable of dealing with 64 bit addresses, but DMA addresses
are truncated causing IOMMU faults when trying to issue operations.
Limit the DMA mask to that of the device, so that DMA allocations
is limited to the range
Hi Johannes,
On Fri, Jan 11, 2019 at 12:59 PM Johannes Weiner wrote:
>
> Hi Shakeel,
>
> On Thu, Jan 10, 2019 at 09:44:32AM -0800, Shakeel Butt wrote:
> > If a memcg is over high limit, memory reclaim is scheduled to run on
> > return-to-userland. However it is assumed that the memcg is the
Quoting Manivannan Sadhasivam (2018-12-31 10:55:11)
> Hello,
>
> This patchset adds common clock support for Actions Semi S500 SoC of
> the Owl family SoCs. This series is based on the initial work done
> by Edgar Bernardi Righi. https://patchwork.kernel.org/cover/10587527/
>
> Since there isn't
On Tue, 8 Jan 2019 11:26:16 +0100
Eric Auger wrote:
> From: "Liu, Yi L"
>
> This patch adds VFIO_IOMMU_SET_PASID_TABLE ioctl which aims at
> passing the virtual iommu guest configuration to the VFIO driver
> downto to the iommu subsystem.
>
> Signed-off-by: Jacob Pan
> Signed-off-by: Liu,
Quoting Tero Kristo (2019-01-03 23:28:58)
> On 04/01/2019 01:39, Stephen Boyd wrote:
> > Quoting Andreas Kemnade (2018-12-31 00:30:21)
> >> On Mon, 31 Dec 2018 09:23:01 +0200
> >> Tero Kristo wrote:
> >>
> >>> On 28/12/2018 22:02, Tony Lindgren wrote:
> * Andreas Kemnade [181227 20:13]:
>
On 1/11/2019 2:30 PM, John Johansen wrote:
> On 1/11/19 2:11 PM, Casey Schaufler wrote:
>> On 1/11/2019 1:43 AM, syzbot wrote:
>>> Hello,
>>>
>>> syzbot found the following crash on:
>>>
>>> HEAD commit: b808822a75a3 Add linux-next spec
On Tue, 8 Jan 2019 11:26:15 +0100
Eric Auger wrote:
> On ARM, MSI are translated by the SMMU. An IOVA is allocated
> for each MSI doorbell. If both the host and the guest are exposed
> with SMMUs, we end up with 2 different IOVAs allocated by each.
> guest allocates an IOVA (gIOVA) to map onto
Quoting Rob Herring (2019-01-11 12:49:04)
> On Fri, Jan 11, 2019 at 12:54 PM Stephen Boyd wrote:
> >
> > Quoting Rob Herring (2019-01-11 10:27:48)
> > > On Fri, Jan 11, 2019 at 11:44 AM Stephen Boyd wrote:
> > > >
> > > > Any pointer to the full schema?
> > >
> > >
On 1/11/19 2:11 PM, Casey Schaufler wrote:
> On 1/11/2019 1:43 AM, syzbot wrote:
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit: b808822a75a3 Add linux-next specific files for 20190111
>> git tree: linux-next
>> co
The bindings for Qualcomm opp levels changed after being Acked but
before landing. Thus the code in the GPU that was relying on the old
bindings is now broken.
While we could just change the string 'qcom,level' to the string
'opp-level', it actually seems better to use the newly-introduced
On Mon, Jan 07, 2019 at 10:53:06AM +0100, Maxime Jourdan wrote:
> Similar to simple-framebuffer-sunxi, we support different display pipelines
> that the firmware is free to choose from.
>
> This documents the "amlogic,simple-framebuffer" compatible and the
> "amlogic,pipeline" extension.
>
>
On Wed 2018-10-24 10:32:37, Theodore Y. Ts'o wrote:
> On Wed, Oct 24, 2018 at 09:15:34AM -0400, Theodore Y. Ts'o wrote:
> > At least for ext4, the primary problem is that we want to use a 64-bit
> > telldir/seekdir cookie if all 64-bits will make it to user space, and
> > a 32-bit telldir cookie
On Mon, 7 Jan 2019 11:28:05 +0800, Joseph Lo wrote:
> The Tegra210 timer provides fourteen 29-bit timer counters and one 32-bit
> timestamp counter. The TMRs run at either a fixed 1 MHz clock rate derived
> from the oscillator clock (TMR0-TMR9) or directly at the oscillator clock
> (TMR10-TMR13).
Hi,
On Wed, Jan 9, 2019 at 8:03 PM Rajendra Nayak wrote:
>
> Add opp-level as an additional property in the OPP node to describe
> the performance level of the device.
>
> On some SoCs (especially from Qualcomm and MediaTek) this value
> is communicated to a remote microprocessor by the CPU,
On Fri, Jan 11, 2019 at 11:06:20PM +0100, Daniel Vetter wrote:
> On Fri, Jan 11, 2019 at 09:02:34AM -0500, Rob Clark wrote:
> > This fixes an '*ERROR* connector VGA-2 leaked!' splat at driver unload.
> >
> > Signed-off-by: Rob Clark
> > ---
> > Similar case to the issue that was fixed recently
On Sun, Jan 06, 2019 at 06:16:14PM +0100, Tomasz Duszynski wrote:
> Add device tree support for Plantower PMS7003 particulate matter sensor.
>
> Signed-off-by: Tomasz Duszynski
> ---
> .../bindings/iio/chemical/plantower,pms7003.txt| 14 ++
> 1 file changed, 14 insertions(+)
>
On Sun, Jan 06, 2019 at 12:09:15AM -0800, Bjorn Andersson wrote:
> The AOSS provides three cooling devices "cx", "mx" and "ebi" that must
> be enabled when temperature goes below a certain level to counter low
> temperature issues. Probe these devices, when described in DeviceTree.
>
>
On Sun, 6 Jan 2019 18:16:13 +0100, Tomasz Duszynski wrote:
> Add Plantower to the vendor prefixes.
>
> Signed-off-by: Tomasz Duszynski
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Rob Herring
On 1/11/2019 1:43 AM, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: b808822a75a3 Add linux-next specific files for 20190111
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=179c22f740
&g
Reuse the string machine from the device tree data structure instead
of duplicating the data again. This also prevents a potential memory
allocation failure that was not handled previously. Also fixes an early
put of root device node.
Reported-by: Nicholas Mc Guire
Signed-off-by: Li Yang
---
> -Original Message-
> From: linux-integrity-ow...@vger.kernel.org ow...@vger.kernel.org> On Behalf Of Stefan Berger
> Sent: Wednesday, January 09, 2019 5:11 PM
> To: linux-integr...@vger.kernel.org; jarkko.sakki...@linux.intel.com
> Cc: linux-security-mod...@vger.kernel.org;
On Sun, 6 Jan 2019 00:09:09 -0800, Bjorn Andersson wrote:
> Add binding for the QMP based side-channel communication mechanism to
> the AOSS, which is used to control resources not exposed through the
> RPMh interface.
>
> Signed-off-by: Bjorn Andersson
> ---
>
> Changes since v1:
> - Don't
Quoting Brian Masney (2019-01-09 17:12:56)
> spmi-gpio did not have any irqchip support so consumers of this in
> device tree would need to call gpio[d]_to_irq() in order to get the
> proper IRQ on the underlying PMIC. IRQ chips in device tree should
> be usable from the start without the consumer
Quoting Brian Masney (2019-01-09 17:12:54)
> Convert the spmi-pmic-arb IRQ code to use the version 2 IRQ interface
> in order to support hierarchical IRQ chips. This is necessary so that
> spmi-gpio can be setup as a hierarchical IRQ chip with pmic-arb as the
> parent. IRQ chips in device tree
On Fri, Jan 11, 2019 at 09:02:34AM -0500, Rob Clark wrote:
> This fixes an '*ERROR* connector VGA-2 leaked!' splat at driver unload.
>
> Signed-off-by: Rob Clark
> ---
> Similar case to the issue that was fixed recently in drm/ast
Reviewed-by: Daniel Vetter
>
>
Quoting Brian Masney (2019-01-09 17:12:55)
> This adds the two new functions gpiochip_irq_domain_activate and
> gpiochip_irq_domain_deactivate that can be used as the activate and
> deactivate functions in the struct irq_domain_ops. This is for
> situations where only gpiochip_{lock,unlock}_as_irq
On Sun, 6 Jan 2019 10:10:10 +0530, wrote:
> From: Akash Gajjar
>
> ROCK Pi 4 is RK3399 based SBC from radxa.com. board has a 1G/2G/4G lpddr4,
> CSI,
> DSI, HDMI, OTG, USB 2.0, USB 3.0, 10/100/1000 RGMII Ethernet Phy, es8316
> codec,
> POE, WIFI (for Model B only), PCIE M.2 support on board.
>
Quoting Brian Masney (2019-01-09 17:12:53)
> @@ -1062,14 +1056,15 @@ static int pmic_gpio_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> +/* data contains the number of GPIOs */
> static const struct of_device_id pmic_gpio_of_match[] = {
> - { .compatible =
> On Jan 11, 2019, at 1:55 PM, Steven Rostedt wrote:
>
> On Fri, 11 Jan 2019 15:41:22 -0600
> Josh Poimboeuf wrote:
>
>>> I don’t see RCU-sched solves the problem if you don’t disable preemption. On
>>> a fully preemptable kernel, you can get preempted between the push and the
>>> call (jmp)
On Fri, 11 Jan 2019, Paul E. McKenney wrote:
> On Fri, Jan 11, 2019 at 12:20:45AM +0100, Andrea Parri wrote:
> > > > I'm not all that exited about spreading version requirements in the
> > > > source: we report this requirement in our README, and apparently we
> > > > already struggle to keep
Quoting Brian Masney (2019-01-09 17:12:58)
> Add interrupt controller properties now that spmi-gpio is a proper
> hierarchical IRQ chip. The interrupts property is no longer needed so
> remove it.
>
> This change was not tested on any hardware but the same change was
> tested on qcom-pm8941.dtsi
Quoting Brian Masney (2019-01-09 17:12:57)
> Add interrupt controller properties now that spmi-gpio is a proper
> hierarchical IRQ chip. The interrupts property is no longer needed so
> remove it. Code was tested on the LG Nexus 5 (hammerhead) phone.
>
> Signed-off-by: Brian Masney
> ---
> On Jan 11, 2019, at 1:41 PM, Josh Poimboeuf wrote:
>
> On Fri, Jan 11, 2019 at 09:36:59PM +, Nadav Amit wrote:
>>> On Jan 11, 2019, at 1:22 PM, Josh Poimboeuf wrote:
>>>
>>> On Fri, Jan 11, 2019 at 12:46:39PM -0800, Linus Torvalds wrote:
On Fri, Jan 11, 2019 at 12:31 PM Josh
On Fri, 11 Jan 2019 15:41:22 -0600
Josh Poimboeuf wrote:
> > I don’t see RCU-sched solves the problem if you don’t disable preemption. On
> > a fully preemptable kernel, you can get preempted between the push and the
> > call (jmp) or before the push. RCU-sched can then finish, and the preempted
On Fri, Jan 11, 2019 at 08:10:03PM +, Mike Kravetz wrote:
> At LPC last year, Boaz Harrosh asked why he had to 'jump through hoops'
> to get an address returned by mmap() suitably aligned for THP. It seems
> that if mmap is asking for a mapping length greater than huge page
> size, it should
Dan,
On 1/11/19 1:38 PM, Dan Murphy wrote:
Jacek
Sorry I missed some replies
On 1/10/19 4:03 PM, Jacek Anaszewski wrote:
On 1/10/19 9:43 PM, Dan Murphy wrote:
Jacek
On 1/10/19 1:57 PM, Jacek Anaszewski wrote:
Dan,
On 1/10/19 8:22 PM, Dan Murphy wrote:
Jacek
On 1/10/19 12:44 PM, Jacek
On Thu, 10 Jan 2019, Vince Weaver wrote:
> On Thu, 10 Jan 2019, Vince Weaver wrote:
>
> > On Thu, 10 Jan 2019, Vince Weaver wrote:
> >
> > > However if you create an all-process attached to CPU event:
> > > perf_event_open(attr, -1, X, -1, 0);
> > > the mmap event index is set as if this were
On 1/11/19 7:07 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.18.132 release.
There are 47 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
Thanks for the overnight fix. This update fixes the issue on my
Skylake XPS13 test device (blind testing since I don't understand what
the code does).
Tested-by: Pierre-Louis Bossart
I need to take this back, this set of changes (initial+fix) causes an
error with our HDMI support
[
On 1/11/19 7:07 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.170 release.
There are 88 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 1/11/19 4:57 PM, Hans van Kranenburg wrote:
> On 1/11/19 3:01 PM, Juergen Gross wrote:
>> On 11/01/2019 14:12, Hans van Kranenburg wrote:
>>> Hi,
>>>
>>> On 1/11/19 1:08 PM, Juergen Gross wrote:
Commit f94c8d11699759 ("sched/clock, x86/tsc: Rework the x86 'unstable'
sched_clock()
On 1/10/19 5:44 PM, Andy Lutomirski wrote:
> On Thu, Jan 10, 2019 at 3:07 PM Kees Cook wrote:
>>
>> On Thu, Jan 10, 2019 at 1:10 PM Khalid Aziz wrote:
>>> I implemented a solution to reduce performance penalty and
>>> that has had large impact. When XPFO code flushes stale TLB entries,
>>> it
On Fri, Jan 11, 2019 at 12:20:45AM +0100, Andrea Parri wrote:
> > > I'm not all that exited about spreading version requirements in the
> > > source: we report this requirement in our README, and apparently we
> > > already struggle to keep this information up-to-date. So what about
> > >
On 1/11/19 7:14 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.9.150 release.
There are 63 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
Den 11.01.2019 22.19, skrev Sam Ravnborg:
> Hi Jagan.
>
> Gave this another more detailed read - triggered some additional comments.
> Depite the comments it looks good, and this is all more or
> less cosmetic improvements.
>
> Sam
>
>> +struct st7701_panel_desc {
>> +const struct
On Fri, Jan 11, 2019 at 09:36:59PM +, Nadav Amit wrote:
> > On Jan 11, 2019, at 1:22 PM, Josh Poimboeuf wrote:
> >
> > On Fri, Jan 11, 2019 at 12:46:39PM -0800, Linus Torvalds wrote:
> >> On Fri, Jan 11, 2019 at 12:31 PM Josh Poimboeuf
> >> wrote:
> >>> I was referring to the fact that a
On 1/11/19 7:13 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.93 release.
There are 105 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 Jan 11, 2019, at 1:22 PM, Josh Poimboeuf wrote:
>
> On Fri, Jan 11, 2019 at 12:46:39PM -0800, Linus Torvalds wrote:
>> On Fri, Jan 11, 2019 at 12:31 PM Josh Poimboeuf wrote:
>>> I was referring to the fact that a single static call key update will
>>> usually result in patching multiple
On 1/11/19 7:12 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.15 release.
There are 148 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 Wed, Jan 09, 2019 at 11:20:50PM +0100, Heiner Kallweit wrote:
> On 28.12.2018 07:39, Heiner Kallweit wrote:
> > On 28.12.2018 07:34, Heiner Kallweit wrote:
> >> On 28.12.2018 02:31, Frederic Weisbecker wrote:
> >>> On Fri, Dec 28, 2018 at 12:11:12AM +0100, Heiner Kallweit wrote:
>
> >>
On 1/11/19 7:14 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.20.2 release.
There are 65 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 Sat, 5 Jan 2019 12:58:57 +0530, Manivannan Sadhasivam wrote:
> Add devicetree binding for HI3670 UFS controller. HI3760 SoC is very
> similar to HI3660 SoC with almost same IPs. Only major difference in terms
> of UFS is the PHY. HI3670 has 10nm PHY. But since the original driver
> (HI3660
On Fri, 4 Jan 2019 19:06:35 -0800, Nicolin Chen wrote:
> By default, ina3221, as a hardware monitor, continuously measures
> the inputs and generates corresponding data. However, for battery
> powered devices, this mode might be power consuming.
>
> This patch adds a "ti,single-shot" property to
On Thu, Jan 10, 2019 at 09:57:41PM +0800, Wei Hu (Xavier) wrote:
> + /* Check the status of the current software reset process, if in
> + * software reset process, wait until software reset process finished,
> + * in order to ensure that reset process and this function will not call
> -Original Message-
> From: Nicholas Mc Guire
> Sent: Thursday, January 10, 2019 8:44 PM
> To: Leo Li
> Cc: Scott Wood ; linuxppc-dev d...@lists.ozlabs.org>; lkml ; moderated
> list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE ker...@lists.infradead.org>; Nicholas Mc Guire
> Subject:
On Fri, Jan 11, 2019 at 01:10:47PM -0800, Linus Torvalds wrote:
> On Fri, Jan 11, 2019 at 1:05 PM Andy Lutomirski wrote:
> >
> > > Yeah, my suggestion doesn't allow for batching, since it would
> > > basically generate one trampoline for every rewritten instruction.
> >
> > Sure it does. Just
On Fri, 4 Jan 2019 16:49:03 -0800, Nicolin Chen wrote:
> By default, ina3221, as a hardware monitor, continuously measures
> the inputs and generates corresponding data. However, for battery
> powered devices, this mode might be power consuming.
>
> This patch adds a "ti,single-shot" property to
On Fri, Jan 11, 2019 at 12:04 PM Rob Herring wrote:
>
> On Fri, Jan 11, 2019 at 1:58 PM Rob Herring wrote:
> >
> > On Thu, Jan 10, 2019 at 11:34 AM John Stultz wrote:
> > >
> > > Some dma channels can be reserved for secure mode or other
> > > hardware on the SoC, so provide a binding for a
On Tue, 8 Jan 2019 11:26:14 +0100
Eric Auger wrote:
> From: "Liu, Yi L"
>
> In any virtualization use case, when the first translation stage
> is "owned" by the guest OS, the host IOMMU driver has no knowledge
> of caching structure updates unless the guest invalidation activities
> are
Hi Uwe
On 2019-01-11 12:48 p.m., Uwe Kleine-König wrote:
On Fri, Jan 11, 2019 at 10:51:14AM +0530, Sheetal Tigadoli wrote:
From: Praveen Kumar B
Add new compatible string for new version of pwm-kona
Signed-off-by: Praveen Kumar B
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
On Fri, Jan 11, 2019 at 03:22:10PM -0600, Josh Poimboeuf wrote:
> b) Adding a gap to the #DB entry stack
And that should be #BP of course... Not sure why my fingers keep doing
that!
--
Josh
On Fri, Jan 11, 2019 at 03:22:10PM -0600, Josh Poimboeuf wrote:
> trampoline:
> push %rax
> call patched-dest
That should be a JMP of course.
--
Josh
101 - 200 of 1414 matches
Mail list logo
