On 9/30/20 11:55 AM, Rajendra Nayak wrote:
On 9/30/2020 1:55 PM, Lukasz Luba wrote:
Hi Douglas,
On 9/30/20 12:53 AM, Doug Anderson wrote:
Hi,
On Tue, Sep 29, 2020 at 5:16 AM Lukasz Luba wrote:
The Energy Model (EM) can store power values in milli-Watts or in
abstract
scale. This migh
On 30/09/2020 16:50:48+0300, Alexandru Ardelean wrote:
> The AT91 ADC driver no longer uses the 'at91_add_device_adc' platform data
> type. This is no longer used (at least in mainline boards).
>
> This change removes the platform-data initialization from the driver, since
> it is mostly dead code
It would be very nice to finally merge this support during the next cycle,
so please take a look.
I think we need acks covering x86, ARM and ACPI. Rafael took a look back
in November at v5 and was looking for x86 and ARM acks. Whilst there is
no ARM specific code left we probably still need an A
Generic Initiators are a new ACPI concept that allows for the
description of proximity domains that contain a device which
performs memory access (such as a network card) but neither
host CPU nor Memory.
This patch has the parsing code and provides the infrastructure
for an architecture to associa
Hi Nathan,
On Tue, Sep 29, 2020 at 03:15:26PM -0700, Nathan Chancellor wrote:
> On Thu, Sep 03, 2020 at 10:01:52AM +0200, Maxime Ripard wrote:
> > Now that all the drivers have been adjusted for it, let's bring in the
> > necessary device tree changes.
> >
> > The VEC and PV3 are left out for now
In common with memoryless domains only register GI domains
if the proximity node is not online. If a domain is already
a memory containing domain, or a memoryless domain there is
nothing to do just because it also contains a Generic Initiator.
Signed-off-by: Jonathan Cameron
---
v12: Update comme
Until we tell ACPI that we support generic initiators, it will have
to operate in fall back domain mode and all _PXM entries should
be on existing non GI domains.
This patch sets the relevant OSC bit to make that happen.
Signed-off-by: Jonathan Cameron
---
drivers/acpi/bus.c | 4
include
Hi dear,
I'm Jessica Vail, from the United States,please i wish to have a
communication with you.
I wait for your answer.
Jessica Vail.
In ACPI 6.3, the Memory Proximity Domain Attributes Structure
changed substantially. One of those changes was that the flag
for "Memory Proximity Domain field is valid" was deprecated.
This was because the field "Proximity Domain for the Memory"
became a required field and hence having a validity
Please version your postings so we know which one to consider as the
current proposal.
On Wed, 30 Sep 2020 20:54:39 +0800
guomin_c...@sina.com wrote:
> From: guomin chen
>
> When the producer object registration fails,In the future, due to
> incorrect matching when unregistering, list_del(&pr
New access1 class is nearly the same as access0, but always provides
characteristics for CPUs to memory. The existing access0 class
provides characteristics to nearest or direct connnect initiator
which may be a Generic Initiator such as a GPU or network adapter.
This new class allows thread pla
On 9/29/20 10:14 PM, Souptick Joarder wrote:
> On Tue, Sep 29, 2020 at 6:00 PM wrote:
>>
>>
>> On 9/29/20 8:09 AM, Souptick Joarder wrote:
>>> On Fri, Sep 11, 2020 at 8:12 PM wrote:
On 9/6/20 2:51 AM, Souptick Joarder wrote:
> In 2019, we introduced pin_user_pages*() and now we a
Try to make minimal changes to the document which already describes
access class 0 in a generic fashion (including IO initiatiors that
are not CPUs).
Signed-off-by: Jonathan Cameron
---
Documentation/admin-guide/mm/numaperf.rst | 8
1 file changed, 8 insertions(+)
diff --git a/Document
My Beloved One,
Greetings to you and your family. My name is Mrs. Birdggie William 58
years childless and widow suffering from Esophageal Cancer, my husband
died after testing positive for the corona virus and recently my
doctor told me that I have a few months to live due to the critical
condition
On 9/24/20 7:49 PM, Stefano Stabellini wrote:
> From: Stefano Stabellini
>
> The VCPUOP_register_runstate_memory_area hypercall takes a virtual
> address of a buffer as a parameter. The semantics of the hypercall are
> such that the virtual address should always be valid.
>
> When KPTI is enabled
On 9/18/20 11:17 PM, Jing Xiangfeng wrote:
> After commit 9f51c05dc41a ("pvcalls-front: Avoid
> get_free_pages(GFP_KERNEL) under spinlock"), the variable ret is being
> initialized with '-ENOMEM' that is meaningless. So remove it.
>
> Signed-off-by: Jing Xiangfeng
Applied to for-linus-5.10
On Wed, Sep 30, 2020 at 01:51:06PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Sep 30, 2020 at 01:27:20PM +0200, Lars Poeschel wrote:
> > On Wed, Sep 30, 2020 at 12:52:38PM +0200, Greg Kroah-Hartman wrote:
> > > On Wed, Sep 30, 2020 at 12:01:26PM +0200, Uwe Kleine-König wrote:
> > > > On Wed, Sep 30
-20200930 (attached as .config)
compiler: microblaze-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://git.kernel.org/pub/scm/linux/kernel/git
On 9/25/20 10:07 AM, Juergen Gross wrote:
> When running as Xen dom0 the kernel isn't responsible for selecting the
> error handling mode, this should be handled by the hypervisor.
>
> So disable setting FF mode when running as Xen pv guest. Not doing so
> might result in boot splats like:
>
> [
AMP_MGR is getting derefernced in hci_phy_link_complete_evt(), when called from
hci_event_packet() and there is a possibility, that hcon->amp_mgr may not be
found when accessing after initialization of hcon.
- net/bluetooth/hci_event.c:4945
The bug seems to get triggered in this line:
bredr_hco
On 9/27/20 1:28 PM, Hui Su wrote:
> arch/x86: fix some typos in xen_pagetable_p2m_free():
> s/Fortunatly/Fortunately
>
> Signed-off-by: Hui Su
Applied to for-linus-5.10 (after rewording slightly the commit message)
-boris
On 29/09/2020 06:34, syzbot wrote:
syzbot has bisected this issue to:
commit 601ef0d52e9617588fcff3df26953592f2eb44ac
Author: Bob Peterson
Date: Tue Jan 28 19:23:45 2020 +
gfs2: Force withdraw to replay journals and wait for it to finish
bisection log: https://syzkaller.appspot.co
On Wed, Sep 30, 2020 at 10:51:01AM -0300, Daniel Gutson wrote:
> This patch serie adds a misc kernel module and extends the intel-spi drivers
> to publish platform integrity data in the sys-fs.
> Please check the comments in the following patches of this serie for further
> details.
>
> Daniel Gut
Hi Thierry
Thanks for your comment
On 2020/09/28 15:59, Thierry Reding wrote:
On Fri, Sep 25, 2020 at 10:52:55PM +0900, Jiada Wang wrote:
Document the mXT1386 compatible string.
Signed-off-by: Jiada Wang
---
Documentation/devicetree/bindings/input/atmel,maxtouch.txt | 1 +
1 file changed,
On 30/09/2020 13:39, syzbot wrote:
Hello,
syzbot found the following issue on:
HEAD commit:fb0155a0 Merge tag 'nfs-for-5.9-3' of git://git.linux-nfs...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13458c0f90
kernel config: https://syzkaller.appspot
Hello Mauro,
On Wed, Sep 30, 2020 at 03:24:42PM +0200, Mauro Carvalho Chehab wrote:
> chanseset b3a7bb1851c8 ("docs: get rid of :c:type explicit declarations for
> structs")
> removed several :c:type: markups, except by one.
>
> Now, Sphinx 3.x complains about it:
>
> .../Documentation/co
On Wed, Sep 30, 2020 at 4:51 PM Thomas Petazzoni
wrote:
>
> Currently, the RX interrupt logic uses the RXEMPTY interrupt, with the
> RXEMPTYINV bit set, which means we get an RX interrupt as soon as the
> RX FIFO is non-empty.
>
> However, with the MAX310X having a FIFO of 128 bytes, this makes ve
On Wed, Sep 30, 2020 at 03:24:45PM +0200, Mauro Carvalho Chehab wrote:
> The :c:type:`foo` only works properly with structs before
> Sphinx 3.x.
>
> On Sphinx 3.x, structs should now be declared using the
> .. c:struct, and referenced via :c:struct tag.
>
> As we now have the automarkup.py macro,
On 9/29/20 5:00 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.8.13 release.
There are 99 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 b
On 9/29/20 4:55 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.4.69 release.
There are 388 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
Add a placeholder for a MAC address. A bootloader may fill it
to set the MAC address and override EEPROM settings.
Signed-off-by: Łukasz Stelmach
---
arch/arm/boot/dts/exynos5422-odroidxu3.dts | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5422-od
From: Kan Liang
When a group that has TopDown members is failed to be scheduled, any
later TopDown groups will not return valid values.
Here is an example.
A background perf that occupies all the GP counters and the fixed
counter 1.
$perf stat -e "{cycles,cycles,cycles,cycles,cycles,cycles,cyc
From: Steven Rostedt
> Sent: 30 September 2020 14:36
>
> On Wed, 30 Sep 2020 10:06:24 +0200
> Rasmus Villemoes wrote:
>
> > True. But remember that printk is called from _everywhere_, with all
> > sorts of locks held and/or preemption disabled or whatnot, and every
> > cycle spent in printk make
On 9/29/20 8:29 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.149 release.
There are 244 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 mad
On Thu, Sep 17, 2020 at 04:01:17PM +0200, Ondřej Jirman wrote:
> Hello Maxime,
>
> On Thu, Sep 17, 2020 at 03:19:04PM +0200, Maxime Ripard wrote:
> > Hi,
> >
> > On Sat, Sep 12, 2020 at 01:22:00PM +0200, Ondrej Jirman wrote:
> > > mfd: sun4i-gpadc: Interrupt numbers should start from 1
> >
> > W
On 9/29/20 5:20 PM, Jarkko Sakkinen wrote:
> On Tue, Sep 29, 2020 at 07:24:24AM -0700, Dave Hansen wrote:
>> On 9/28/20 9:05 PM, Jarkko Sakkinen wrote:
>>> On Mon, Sep 28, 2020 at 06:37:54PM -0700, Andy Lutomirski wrote:
I don’t personally care that much about EMODPE but, you could probably
>>
On Sun 2020-09-27 19:05:34, psoda...@codeaurora.org wrote:
> Yes. I agree with you that there are other conditions, which could delay the
> hotplug operation. But this console
> flushing is not needed in the hotplug path. In the hotplug path, a core is
> trying printing messages
> from other core(
st 30. 9. 2020 o 15:04 Colin King napísal(a):
>
> From: Colin Ian King
>
> There is an off-by-one range check on the upper limit of
> index "no". Fix this by changing the > comparison to >=
Note that this doesn't completely fix the bug though... (see below)
>
> Addresses-Coverity: ("Out-of-bou
On Thu, 2020-09-24 at 19:33 +0200, Paolo Bonzini wrote:
> On 21/09/20 12:38, Maxim Levitsky wrote:
> > MSR reads/writes should always access the L1 state, since the (nested)
> > hypervisor should intercept all the msrs it wants to adjust, and these
> > that it doesn't should be read by the guest as
On 9/29/20 4:58 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.200 release.
There are 166 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 mad
On 9/30/20 12:07 AM, Uladzislau Rezki wrote:
> On Tue, Sep 29, 2020 at 12:15:34PM +0200, Vlastimil Babka wrote:
>> On 9/18/20 9:48 PM, Uladzislau Rezki (Sony) wrote:
>>
>> After reading all the threads and mulling over this, I am going to deflect
>> from
>> Mel and Michal and not oppose the idea
On 9/29/20 4:59 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.9.238 release.
There are 121 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 Wed, 2020-09-30 at 13:27 +0300, Mike Rapoport wrote:
> On Tue, Sep 29, 2020 at 05:15:52PM +0200, Peter Zijlstra wrote:
> > On Tue, Sep 29, 2020 at 05:58:13PM +0300, Mike Rapoport wrote:
> > > On Tue, Sep 29, 2020 at 04:12:16PM +0200, Peter Zijlstra wrote:
> > > > It will drop them down to 4k pag
...
> +struct tegra_mc *devm_tegra_get_memory_controller(struct device *dev)
> +{
> + struct platform_device *pdev;
> + struct device_node *np;
> + struct tegra_mc *mc;
> + int err;
> +
> + np = of_find_matching_node_and_match(NULL, tegra_mc_of_match, NULL);
> + if (!np)
> +
...
> + struct tegra_mc *mc = devm_tegra_get_memory_controller(dev);
> + struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
>
> - of_node_put(args.np);
> - index++;
> - }
> + /* An invalid mc pointer means mc and smmu drivers are not ready */
> +
On Wed, Sep 30, 2020 at 03:24:43PM +0200, Mauro Carvalho Chehab wrote:
> As warned by Sphinx:
>
> ./Documentation/gpu/drm-kms-helpers:305: ./include/drm/drm_dsc.h:587:
> WARNING: Unparseable C cross-reference: 'struct'
> Invalid C declaration: Expected identifier in nested name, got k
On 9/30/2020 3:15 AM, Stephane Eranian wrote:
+static u64 perf_get_page_size(unsigned long addr)
+{
+ unsigned long flags;
+ u64 size;
+
+ if (!addr)
+ return 0;
+
+ /*
+* Software page-table walkers must disable IRQs,
+* which prevents any
On Fri, 18 Sep 2020, Thomas Bogendoerfer wrote:
> > IRQ_CPU_RM7K has been a non-visible config selected nowhere since
> > PMC-Sierra Yosemite support has been removed with commit bdf20507da11
> > ("MIPS: PMC-Sierra Yosemite: Remove support."). By the same token, the
> > handler for RM7000 extended
On Wed, Sep 30, 2020 at 7:49 AM Matthias Kaehlcke wrote:
>
> Hi Alan,
>
> On Tue, Sep 29, 2020 at 09:32:29PM -0400, Alan Stern wrote:
> > On Tue, Sep 29, 2020 at 03:09:12PM -0700, Matthias Kaehlcke wrote:
> > > Hi Rob,
> > >
> > > On Tue, Sep 29, 2020 at 03:17:01PM -0500, Rob Herring wrote:
> > >
On Wed, Sep 30, 2020 at 04:11:15PM +0300, Serge Semin wrote:
> On Wed, Sep 30, 2020 at 12:04:04PM +0100, Mark Brown wrote:
> > Not all of the first 9, IIRC I skipped one I had comments on.
> Yes, you skipped one and I've already given you my response on your comment
> about it: [PATCH 02/30] spi:
On 30.09.20 16:39, James Bottomley wrote:
> On Wed, 2020-09-30 at 13:27 +0300, Mike Rapoport wrote:
>> On Tue, Sep 29, 2020 at 05:15:52PM +0200, Peter Zijlstra wrote:
>>> On Tue, Sep 29, 2020 at 05:58:13PM +0300, Mike Rapoport wrote:
On Tue, Sep 29, 2020 at 04:12:16PM +0200, Peter Zijlstra wro
On Wed, 30 Sep 2020 at 16:41, Dmitry Osipenko wrote:
>
> ...
> > +struct tegra_mc *devm_tegra_get_memory_controller(struct device *dev)
> > +{
> > + struct platform_device *pdev;
> > + struct device_node *np;
> > + struct tegra_mc *mc;
> > + int err;
> > +
> > + np = of_find_ma
The purpose of this patch series is to introduce a new CAN USB
driver to support ETAS USB interfaces (ES58X series).
During development, issues in drivers/net/can/dev.c where discovered,
the fix for those issues are included in this patch series.
We also propose to add two helper functions in inc
On 9/30/20 7:42 AM, Liang, Kan wrote:
>> When I tested on my kernel, it panicked because I suspect
>> current->active_mm could be NULL. Adding a check for NULL avoided the
>> problem. But I suspect this is not the correct solution.
>
> I guess the NULL active_mm should be a rare case. If so, I thi
On Tue, Sep 29, 2020 at 03:43:30PM +0300, Joonas Lahtinen wrote:
> Hmm, those are both committed after our last -next pull request, so they
> would normally only target next merge window. drm-next closes the merge
> window around -rc5 already.
>
> But, in this specific case those are both Fixes: p
If a driver calls can_get_echo_skb() during a hardware IRQ (which is
often, but not always, the case), the 'WARN_ON(in_irq)' in
net/core/skbuff.c#skb_release_head_state() might be triggered, under
network congestion circumstances, together with the potential risk of
a NULL pointer dereference.
The
Hello,
On Wed, 30 Sep 2020 17:24:48 +0300
Andy Shevchenko wrote:
> > On a Microchip SAMA5D3 platform that is receiving 20 bytes every 16ms
> > over one MAX310X UART, this patch has allowed to reduce the CPU
> > consumption of the interrupt handler thread from ~25% to 6-7%.
>
> Was it always l
On Wed, Sep 30, 2020 at 01:59:19PM +0200, Jan Kara wrote:
> > @@ -931,33 +904,39 @@ static void shmem_undo_range(struct inode *inode,
> > loff_t lstart, loff_t lend,
> > index++;
> > }
> >
> > - if (partial_start) {
> > - struct page *page = NULL;
> > - shme
In classical CAN, the length of the data (i.e. CAN payload) is not
always equal to the DLC! If the frame is a Remote Transmission Request
(RTR), data length is always zero regardless of DLC value and else, if
the DLC is greater than 8, the length is 8. Contrary to common belief,
ISO 11898-1 Chapter
Good Day, I am glad to contact you through this medium I’m Sgt Vivian Robert am
from united state, 28 years old single I am the only surviving child of my late
parents, I am America female soldier presently in Afghanistan for the training,
advising the Afghan forces and also helping in stabil
The length of Remote Transmission Request (RTR) frames is always 0
bytes. The DLC represents the requested length, not the actual length
of the RTR. But __can_get_echo_skb() returns the DLC value regardless.
Apply get_can_len() function to retrieve the correct length.
Signed-off-by: Vincent Mailh
...
> +#ifdef CONFIG_PCI
> + if (!iommu_present(&pci_bus_type)) {
In the previous reply you said that you're borrowing this check from the
arm-smmu driver, but arm-smmu also has a similar check for
platform_bus_type, while Tegra SMMU driver doesn't have it. Hence I'm
objecting the necessity o
Since commit d5fab59cab18 ("spi: atmel: trivial: remove unused fields in
DMA structure"), the driver is not using any definitions from
linux/platform_data/dma-atmel.h, stop including it.
Signed-off-by: Alexandre Belloni
---
drivers/spi/spi-atmel.c | 1 -
1 file changed, 1 deletion(-)
diff --git
Since commit 95e0e07e710e ("ASoC: atmel-pcm: use generic dmaengine
framework"), the driver is using dmaengine and is not using any definition
from include/linux/platform_data/dma-atmel.h, stop including it.
Signed-off-by: Alexandre Belloni
---
sound/soc/atmel/atmel-pcm-dma.c | 1 -
1 file change
On Wed, Sep 30, 2020 at 5:50 PM Thomas Petazzoni
wrote:
> On Wed, 30 Sep 2020 17:24:48 +0300
> Andy Shevchenko wrote:
> > > On a Microchip SAMA5D3 platform that is receiving 20 bytes every 16ms
> > > over one MAX310X UART, this patch has allowed to reduce the CPU
> > > consumption of the interru
Rename macro CAN_CALC_SYNC_SEG to CAN_SYNC_SEG and make it available
through include/linux/can/dev.h
Add an helper function can_bit_time() which returns the duration (in
time quanta) of one CAN bit.
Rationale for this patch: the sync segment and the bit time are two
concepts which are defined in
On Wed, 30 Sep 2020 15:24:51 +0200,
Mauro Carvalho Chehab wrote:
>
> The sound API is documented on two different parts:
> under Documentation/driver-api/sound.rst and under
> Documentation/sound/kernel-api/alsa-driver-api.rst.
>
> The alsa-driver-api.rst seems more complete, and APIs
> are split
Commit dc6df6e90de9 ("i2c: at91: remove legacy DMA support") removed legcy
DMA support from the driver. Remove the last use of the definitions from
linux/platform_data/dma-atmel.h and stop including this header.
Signed-off-by: Alexandre Belloni
---
drivers/i2c/busses/i2c-at91-master.c | 1 -
dri
On Wed, 30 Sep 2020 15:25:02 +0200,
Mauro Carvalho Chehab wrote:
>
> Some such markups are invalid, as reported by Sphinx:
>
> ./Documentation/sound/kernel-api/writing-an-alsa-driver.rst:3317:
> WARNING: Unparseable C cross-reference: 'snd_rawmidi_transmit*'
> Invalid C declaration:
Mark,
A concrete question is below the main text.)
On Wed, Sep 30, 2020 at 12:55:55AM +0300, Serge Semin wrote:
> On Tue, Sep 29, 2020 at 02:11:53PM +0100, Mark Brown wrote:
> > On Sun, Sep 20, 2020 at 02:28:46PM +0300, Serge Semin wrote:
> > > Simplify the dw_spi_add_host() method a bit by replac
A temporary var needed for building with ISP2401 was removed
by accident on a cleanup patch.
Fix the breakage.
Fixes: 852a53a02cf0 ("media: atomisp: get rid of unused vars")
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/media/atomisp/pci/sh_css.c | 3 +--
1 file changed, 1 insertion(
The ES58X devices has a CDC ACM interface (used for debug
purpose). During probing, the device is thus recognized as USB Modem
(CDC ACM), preventing the etas-es58x module to load:
usbcore: registered new interface driver etas_es58x
usb 1-1.1: new full-speed USB device number 14 using xhci_hcd
On Wed, 30 Sep 2020 15:25:00 +0200,
Mauro Carvalho Chehab wrote:
>
> the :c:type shouldn't be used with structs with Sphinx 3,
> as the C domain there uses .. c:struct for structs.
>
> As we have the automarkup extension, let's just get rid of
> all :c:type as a hole, as those will be automagical
A temporary var needed for building with ISP2400 was removed
by accident on a cleanup patch.
Fix the breakage.
Fixes: 852a53a02cf0 ("media: atomisp: get rid of unused vars")
Signed-off-by: Mauro Carvalho Chehab
---
v2: fixed a typo at comment: ISP2401 -> ISP2400
drivers/staging/media/atomisp/
On Wed, 30 Sep 2020 15:24:45 +0200,
Mauro Carvalho Chehab wrote:
>
> The :c:type:`foo` only works properly with structs before
> Sphinx 3.x.
>
> On Sphinx 3.x, structs should now be declared using the
> .. c:struct, and referenced via :c:struct tag.
>
> As we now have the automarkup.py macro, th
On Sat 2020-09-26 12:04:26, Hillf Danton wrote:
>
> It does not make much sense to rearm timer for the delayed work if
> it is worker's current work atm because it's good to do work only
> once.
Quite typical scenario is to queue delayed work from its own callback.
It allows to do the work in reg
On Wed, Sep 30, 2020 at 8:22 AM Kishon Vijay Abraham I wrote:
>
> Hi,
>
> On 29/09/20 10:41 pm, Rob Herring wrote:
> > On Tue, Sep 29, 2020 at 10:24 AM Gustavo Pimentel
> > wrote:
> >>
> >> On Tue, Sep 29, 2020 at 5:5:41, Z.q. Hou wrote:
> >>
> >>> Hi Lorenzo,
> >>>
> >>> Thanks a lot for your c
On Wed, Sep 30, 2020 at 05:57:59PM +0300, Serge Semin wrote:
> On Wed, Sep 30, 2020 at 12:55:55AM +0300, Serge Semin wrote:
> > + if (dws->set_cs)
> > + master->set_cs = dws->set_cs;
> > + else
> > + master->set_cs = dw_spi_set_cs;
> Judging by having your comment on this
Mark,
A concrete question is below of my previous comment.
On Wed, Sep 30, 2020 at 01:17:37AM +0300, Serge Semin wrote:
> On Tue, Sep 29, 2020 at 02:52:33PM +0100, Mark Brown wrote:
> > On Sun, Sep 20, 2020 at 02:28:55PM +0300, Serge Semin wrote:
> >
> > > - /*
> > > - * SPI mode (SCPOL|SCPH)
>
On Wed, Sep 30, 2020 at 04:13:52PM +0200, Lars Poeschel wrote:
> On Wed, Sep 30, 2020 at 01:51:06PM +0200, Greg Kroah-Hartman wrote:
> > On Wed, Sep 30, 2020 at 01:27:20PM +0200, Lars Poeschel wrote:
> > > On Wed, Sep 30, 2020 at 12:52:38PM +0200, Greg Kroah-Hartman wrote:
> > > > On Wed, Sep 30, 2
On 9/30/2020 2:58 PM, Jason Gunthorpe wrote:
On Wed, Sep 30, 2020 at 02:53:58PM +0300, Maor Gottlieb wrote:
On 9/30/2020 2:45 PM, Jason Gunthorpe wrote:
On Wed, Sep 30, 2020 at 12:53:21PM +0300, Leon Romanovsky wrote:
On Tue, Sep 29, 2020 at 04:59:29PM -0300, Jason Gunthorpe wrote:
On Sun,
Greetings,
I am delighted to write you this mail. Nowadays internet has been highly
abused. But i can assure you my claims are real and genuine. I am Prince Rassaq
Rasmane, a young African who is passionate about the living standards of his
people. I am contacting you on behalf of my father the
On Wed, Sep 30, 2020 at 8:29 AM Kishon Vijay Abraham I wrote:
>
> Hi Hou,
>
> On 29/09/20 6:43 pm, Zhiqiang Hou wrote:
> > From: Hou Zhiqiang
> >
> > In the current error response behavior, it will send a SLVERR response
> > to device's internal AXI slave system interface when the PCIe controller
On Wed, Sep 30, 2020 at 04:01:17PM +0100, Mark Brown wrote:
> On Wed, Sep 30, 2020 at 05:57:59PM +0300, Serge Semin wrote:
> > On Wed, Sep 30, 2020 at 12:55:55AM +0300, Serge Semin wrote:
>
> > > + if (dws->set_cs)
> > > + master->set_cs = dws->set_cs;
> > > + else
> > > + master->
Hello,
This series adds PCIe support for Qualcomm SM8250 SoC with relevant PHYs.
There are 3 PCIe instances on this SoC each with different PHYs. The PCIe
controller and PHYs are mostly comaptible with the ones found on SDM845
SoC, hence the old drivers are modified to add the support.
This serie
SM8250 has multiple different PHY versions:
QMP GEN3x1 PHY - 1 lane
QMP GEN3x2 PHY - 2 lanes
QMP Modem PHY - 2 lanes
Add support for these with relevant init sequence. In order to abstract
the init sequence, this commit introduces secondary tables which can
be used to factor out the unique sequenc
Add the below three PCIe PHYs found in SM8250 to the QMP binding:
QMP GEN3x1 PHY - 1 lane
QMP GEN3x2 PHY - 2 lanes
QMP Modem PHY - 2 lanes
Signed-off-by: Manivannan Sadhasivam
---
Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml | 6 ++
1 file changed, 6 insertions(+)
diff --git a/D
For SM8250, we need to write the BDF to SID mapping in PCIe controller
register space for proper working. This is accomplished by extracting
the BDF and SID values from "iommu-map" property in DT and writing those
in the register address calculated from the hash value of BDF. In case
of collisions,
The PCIe IP on SM8250 SoC is similar to the one used on SDM845. Hence
the support is added reusing the members of ops_2_7_0. The key
difference between ops_2_7_0 and ops_sm8250 is the config_sid callback,
which will be added in successive commit.
Signed-off-by: Manivannan Sadhasivam
---
drivers/
On Wed, Sep 30, 2020 at 01:27:45PM +0300, Mike Rapoport wrote:
> On Tue, Sep 29, 2020 at 05:15:52PM +0200, Peter Zijlstra wrote:
> > On Tue, Sep 29, 2020 at 05:58:13PM +0300, Mike Rapoport wrote:
> > > On Tue, Sep 29, 2020 at 04:12:16PM +0200, Peter Zijlstra wrote:
> >
> > > > It will drop them do
Document the PCIe DT bindings for SM8250 SoC. The PCIe IP is similar to
the one used on SDM845, hence just add the compatible along with the
optional "atu" register region.
Signed-off-by: Manivannan Sadhasivam
---
Documentation/devicetree/bindings/pci/qcom,pcie.txt | 6 --
1 file changed, 4
Document the mXT1386 compatible string.
Signed-off-by: Jiada Wang
---
Documentation/devicetree/bindings/input/atmel,maxtouch.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
b/Documentation/devicetree/bindings/input/atmel,maxtouc
According to datasheet, mXT1386 chip has a WAKE line, it is used
to wake the chip up from deep sleep mode before communicating with
it via the I2C-compatible interface.
if the WAKE line is connected to a GPIO line, the line must be
asserted 25 ms before the host attempts to communicate with th
According to datasheet, mXT1386 chip has a WAKE line, it is used
to wake the chip up from deep sleep mode before communicating with
it via the I2C-compatible interface.
if the WAKE line is connected to a GPIO line, the line must be
asserted 25 ms before the host attempts to communicate with the mX
Add mXT1386 compatible for "touchscreen@4c".
Signed-off-by: Jiada Wang
---
arch/arm/boot/dts/tegra20-acer-a500-picasso.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts
b/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts
index
On Wed, Sep 30, 2020 at 06:05:15PM +0300, Maor Gottlieb wrote:
> This is right only for the last iteration. E.g. in the first iteration in
> case that there are more pages (left_pages), then we allocate
> SG_MAX_SINGLE_ALLOC. We don't know how many pages from the second iteration
> will be squashe
On Wed, 30 Sep 2020 16:53:30 +0200, Alexandre Belloni wrote:
> Since commit 95e0e07e710e ("ASoC: atmel-pcm: use generic dmaengine
> framework"), the driver is using dmaengine and is not using any definition
> from include/linux/platform_data/dma-atmel.h, stop including it.
Applied to
https://g
On Wed, 30 Sep 2020 16:53:52 +0200, Alexandre Belloni wrote:
> Since commit d5fab59cab18 ("spi: atmel: trivial: remove unused fields in
> DMA structure"), the driver is not using any definitions from
> linux/platform_data/dma-atmel.h, stop including it.
Applied to
https://git.kernel.org/pub/sc
Em Wed, 30 Sep 2020 17:23:23 +0300
Mike Rapoport escreveu:
> Hello Mauro,
>
> On Wed, Sep 30, 2020 at 03:24:42PM +0200, Mauro Carvalho Chehab wrote:
> > chanseset b3a7bb1851c8 ("docs: get rid of :c:type explicit declarations for
> > structs")
> > removed several :c:type: markups, except by one.
On Wed, Sep 30, 2020 at 09:03:36AM -0600, Tycho Andersen wrote:
> On Wed, Sep 30, 2020 at 01:07:38PM +0200, Michael Kerrisk (man-pages) wrote:
> >┌─┐
> >│FIXME│
> >├──
401 - 500 of 1591 matches
Mail list logo
