Some UDCs may have constraints on how many high bandwidth endpoints it can
support in a certain configuration. This API allows for the composite
driver to pass down the total number of endpoints to the UDC so it can verify
it has the required resources to support the configuration.
Re-introduce the comment for the tx-fifo-resize setting for the DWC3
controller. This allows for vendors to control if they require the TX FIFO
resizing logic on their HW, as the default FIFO size configurations may
already be sufficient.
Signed-off-by: Wesley Cheng
Acked-by: Rob Herring
---
Enable the flexible TX FIFO resize logic on SM8150. Using a larger TX FIFO
SZ can help account for situations when system latency is greater than the
USB bus transmission latency.
Signed-off-by: Wesley Cheng
---
arch/arm64/boot/dts/qcom/sm8150.dtsi | 1 +
1 file changed, 1 insertion(+)
diff
Changes in V5:
- Added check_config() logic, which is used to communicate the number of EPs
used in a particular configuration. Based on this, the DWC3 gadget driver
has the ability to know the maximum number of eps utilized in all configs.
This helps reduce unnecessary allocation to
Some devices have USB compositions which may require multiple endpoints
that support EP bursting. HW defined TX FIFO sizes may not always be
sufficient for these compositions. By utilizing flexible TX FIFO
allocation, this allows for endpoints to request the required FIFO depth to
achieve higher
> Subject: RE: [RFC] sched/topology: NUMA topology limitations
>
> > Subject: [RFC] sched/topology: NUMA topology limitations
> >
> > (For those of you who already got this one: sorry! I messed up LKML and
> > Vincent's addresses)
> >
> > Hi,
> >
> > Some of you may have noticed me struggling to
> Subject: [RFC] sched/topology: NUMA topology limitations
>
> (For those of you who already got this one: sorry! I messed up LKML and
> Vincent's addresses)
>
> Hi,
>
> Some of you may have noticed me struggling to plug some topology holes in
> [1]. While digging in there I realized there are
includes too many unneeded headers.
This commit cuts off a lot of header includes.
What we need to include are:
- for DECLARE_PER_CPU(u64, ia64_mca_pal_base)
- for NR_CPUS
- for u8, u64, size_t, etc.
- for KERNEL_STACK_SIZE
The other header includes are actually unneeded.
previously
Randy Dunlap reports the following warning with CONFIG_IA64_PALINFO=m:
../scripts/Makefile.build:68: 'arch/ia64/kernel/palinfo.ko' will not be built
even though obj-m is specified.
../scripts/Makefile.build:69: You cannot use subdir-y/m to visit a module
Makefile. Use obj-y/m instead.
This
Randy reports the following warning when building ARCH=ia64 with
CONFIG_IA64_PALINFO=m:
../scripts/Makefile.build:68: 'arch/ia64/kernel/palinfo.ko' will not be built
even though obj-m is specified.
../scripts/Makefile.build:69: You cannot use subdir-y/m to visit a module
Makefile. Use obj-y/m
Documentation/process/coding-style.rst says:
Please don't use things like ``vps_t``.
It's a **mistake** to use typedef for structures and pointers.
This commit converts as follows:
struct pal_min_state_area_s -> struct pal_min_state_area
pal_min_state_area_t -> struct
Hi Luca,
I love your patch! Perhaps something to improve:
[auto build test WARNING on v5.9-rc2]
[also build test WARNING on next-20200828]
[cannot apply to xlnx/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base
On 2020-08-28 18:05, Bao D. Nguyen wrote:
> static ssize_t auto_hibern8_show(struct device *dev,
>struct device_attribute *attr, char *buf)
> {
> + u32 ahit;
> struct ufs_hba *hba = dev_get_drvdata(dev);
Although not strictly required for SCSI code, how
samples/seccomp/user-trap.c is compiled with $(userccflags), and the
latter does not contain -fno-strict-aliasing, so the warnings reported as
below. Due to add "userccflags += -fno-strict-aliasin" will impact other
files, so use __attribute__((__may_alias__)) to suppress it exactly.
My gcc
> I'm curious whether it is correct to just set the prev->refs to zero and
> return
> @prev? So that it can remove an unneeded "add()()" pair (although in
> an unlikely branch) and __freelist_add() can be folded into freelist_add()
> for tidier code.
That is a very good question. I believe it
When ext4_journal_get_write_access() fails, we should
terminate the execution flow and release n_group_desc,
iloc.bh, dind and gdb_bh.
Signed-off-by: Dinghao Liu
---
Changelog:
v2: - Remove changes to ext4_handle_dirty_super()'s
error handling path.
---
fs/ext4/resize.c | 4 +++-
1 file
On 8/29/2020 9:49 AM, Chenyi Qiang wrote:
On 8/29/2020 1:43 AM, Jim Mattson wrote:
On Fri, Aug 28, 2020 at 1:54 AM Chenyi Qiang
wrote:
KVM supports the nested VM_{EXIT, ENTRY}_LOAD_IA32_PERF_GLOBAL_CTRL and
VM_{ENTRY_LOAD, EXIT_CLEAR}_BNDCFGS, but they doesn't expose during
the setup of
From: Dan Crawford
Following Christian Lachner's patch for Gigabyte X570-based motherboards,
also patch the MSI X570-A PRO motherboard; the ALC1220 codec requires the
same workaround for Clevo laptops to enforce the DAC/mixer connection
path. Set up a quirk entry for that.
I suspect most if all
ChiYuan Huang 於 2020年8月29日 週六 上午8:32寫道：
>
> Rob Herring 於 2020年8月29日 週六 上午6:05寫道：
> >
> > On Fri, Aug 28, 2020 at 06:30:36PM +0800, cy_huang wrote:
> > > From: ChiYuan Huang
> > >
> > > Add a devicetree binding documentation for the MT6360 Type-C driver.
> > >
> > > usb typec: mt6360: Rename DT
> On Thu 27-08-20 14:28:43, Dinghao Liu wrote:
> > When ext4_journal_get_write_access() fails, we should release
> > n_group_desc, iloc.bh, dind and gdb_bh to prevent memleak.
> > It's the same when ext4_handle_dirty_super() fails, but we
> > don't need to release dind here because it has been
On Fri, Aug 28, 2020 at 10:29 PM Cameron wrote:
> I thought about this some more, and actually, it should be safe.
Although I should note that it's important that the flags/refcount are
not overwritten
even after the node is taken off the freelist.
Cameron
On Fri, Aug 28, 2020 at 5:18 AM wrote:
> So the freelist->refs thing is supposed to pin freelist->next for
> concurrent usage, but if we instantly stick it on the
> current->kretprobe_instances llist while it's still elevated, we'll
> overwrite ->next, which would be bad.
I thought about this
Hi Miquèl,
Thanks for your feedback.
I have just rechecked this function and find that "pdev" currently is
already put
inside ck804xrom_cleanup, so my previous patch is meaningless...
The current calling order is like:
window->pdev = pci_dev_get(pdev);
...
ck804xrom_cleanup(window)
This change will speed-up a bit these ipu_idmac_get &
ipu_idmac_put processing and there is no need to protect
kzalloc & kfree.
Signed-off-by: Bernard Zhao
---
drivers/gpu/ipu-v3/ipu-common.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git
On Fri, 28 Aug 2020 21:29:55 +0900
Masami Hiramatsu wrote:
> From: Peter Zijlstra
In the next version I will drop this since I will merge the kretprobe_holder
things into removing kretporbe hash patch.
However, this patch itself seems fixing a bug of commit 2beaf3280e57
("sched/core: Add
The pwrite function, originally defined by POSIX (thus the "p"), is
defined to ignore O_APPEND and write at the offset passed as its
argument. However, historically Linux honored O_APPEND if set and
ignored the offset. This cannot be changed due to stability policy,
but is documented in the man
Asynchronous termination of a thread outside of the userspace thread
library's knowledge is an unsafe operation that leaves the process in
an inconsistent, corrupt, and possibly unrecoverable state. In order
to make new actions that may be added in the future safe on kernels
not aware of them,
Hi Herbert,
I just noticed a small potential issue about the calling sequence of
pci_disable_device and dev_err.
Do you think it will be better to call dev_err before we call
pci_disable_device(pdev) , or the order here does not matter?
On Fri, Aug 28, 2020 at 2:19 AM Herbert Xu wrote:
>
> On
On 8/29/2020 1:43 AM, Jim Mattson wrote:
On Fri, Aug 28, 2020 at 1:54 AM Chenyi Qiang wrote:
KVM supports the nested VM_{EXIT, ENTRY}_LOAD_IA32_PERF_GLOBAL_CTRL and
VM_{ENTRY_LOAD, EXIT_CLEAR}_BNDCFGS, but they doesn't expose during
the setup of nested VMX controls MSR.
Aren't these
On Fri, Aug 28, 2020 at 04:37:19PM +0200, Linus Walleij wrote:
> On Fri, Aug 28, 2020 at 12:47 AM Kent Gibson wrote:
>
> > The particular use case I am considering is one I had been asked about -
> > changing a requested line from input with edge detection to output, and
> > vice versa. Losing
On Fri, Aug 28, 2020 at 05:52:16AM -0700, syzbot wrote:
> syzbot has found a reproducer for the following issue on:
>
> HEAD commit:15bc20c6 Merge tag 'tty-5.9-rc3' of git://git.kernel.org/p..
> git tree: upstream
> console output:
On Fri, 28 Aug 2020 22:29:12 +0200
Peter Zijlstra wrote:
> On Fri, Aug 28, 2020 at 07:32:11PM +, eddy...@trendmicro.com wrote:
> >
> > > -Original Message-
> > > From: Masami Hiramatsu
> > >
> > > @@ -1311,24 +1257,23 @@ void kprobe_busy_end(void)
> > > void
Fixed some coding style issues.
Signed-off-by: Ross Schmidt
---
drivers/staging/rtl8723bs/os_dep/sdio_intf.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
index f1e2829a19a7..2b2f4505b98b 100644
On Fri, Aug 28, 2020 at 9:15 AM Bjorn Helgaas wrote:
>
> On Fri, Aug 28, 2020 at 10:48:30AM +0100, Jonathan Cameron wrote:
> > On Fri, 14 Aug 2020 14:47:22 -0700
> > Atish Patra wrote:
> >
> > > pcibus_to_node is used only when numa is enabled and does not depend
> > > on ISA. Thus, it can be
Just merged the first patch that fixed this issue, thanks anyways.
2034c2129bc4a91d471815d4dc7a2a69eaa5338d - drm/i915/display: Ensure that ret is
always initialized in icl_combo_phy_verify_state
On Tue, 2020-08-25 at 16:20 -0700, t...@redhat.com wrote:
> From: Tom Rix <
> t...@redhat.com
> >
In kernel 5.9.0-rc1 on a PowerBook G4 (ppc32), several warnings of the following
type are logged:
[ cut here ]
WARNING: CPU: 0 PID: 1 at arch/powerpc/mm/pgtable.c:185 set_pte_at+0x20/0x100
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 5.9.0-rc2 #2
NIP:
The zero value Auto-Hibernate Timer is a valid setting, and it
indicates the Auto-Hibernate feature being disabled. Correctly
support this setting. In addition, when this value is queried
from sysfs, read from the host controller's register and return
that value instead of using the RAM value.
add debugfs node for querying rq info, for example:
cat /sys/kernel/debug/hinic/:15:00.0/RQs/0x0/rq_hw_pi
Signed-off-by: Luo bin
---
V0~V1:
- remove command interfaces to the read only files
- split addition of each object into a separate patch
.../net/ethernet/huawei/hinic/hinic_debugfs.c
add debugfs node for querying sq info, for example:
cat /sys/kernel/debug/hinic/:15:00.0/SQs/0x0/sq_pi
Signed-off-by: Luo bin
---
V0~V1:
- remove command interfaces to the read only files
- split addition of each object into a separate patch
drivers/net/ethernet/huawei/hinic/Makefile|
add debugfs node for querying function table, for example:
cat /sys/kernel/debug/hinic/:15:00.0/func_table/valid
Signed-off-by: Luo bin
---
V0~V1:
- remove command interfaces to the read only files
- split addition of each object into a separate patch
V1~V2:
- remove vlan_id and vlan_mode
add debugfs node for querying sq/rq info and function table
Luo bin (3):
hinic: add support to query sq info
hinic: add support to query rq info
hinic: add support to query function table
drivers/net/ethernet/huawei/hinic/Makefile| 3 +-
.../net/ethernet/huawei/hinic/hinic_debugfs.c
On Fri, Aug 28, 2020 at 01:03:00PM -0400, Rich Felker wrote:
> On Fri, Aug 28, 2020 at 06:38:09PM +0200, John Paul Adrian Glaubitz wrote:
> > Hi!
> >
> > On 8/28/20 6:30 PM, Rich Felker wrote:
> > > I'm about to test a patch along these lines and will report what I
> > > find.
> >
> > Let me
On 2020/8/29 1:19, Jakub Kicinski wrote:
> On Fri, 28 Aug 2020 11:16:22 +0800 luobin (L) wrote:
>> On 2020/8/28 3:44, Jakub Kicinski wrote:
>>> On Thu, 27 Aug 2020 19:13:21 +0800 Luo bin wrote:
+ switch (idx) {
+ case VALID:
+ return funcfg_table_elem->dw0.bs.valid;
On Fri, Aug 28, 2020 at 2:37 AM Jonathan Cameron
wrote:
>
> On Fri, 14 Aug 2020 14:47:21 -0700
> Atish Patra wrote:
>
> > As we are using generic numa implementation code, modify the init function
> > name to indicate that generic implementation.
> >
> > Signed-off-by: Atish Patra
> > ---
> >
Rob Herring 於 2020年8月29日 週六 上午6:06寫道：
>
> On Fri, Aug 28, 2020 at 06:30:36PM +0800, cy_huang wrote:
> > From: ChiYuan Huang
> >
> > Add a devicetree binding documentation for the MT6360 Type-C driver.
> >
> > usb typec: mt6360: Rename DT binding doument from mt6360 to mt636x
> >
> >
Rob Herring 於 2020年8月29日 週六 上午6:05寫道：
>
> On Fri, Aug 28, 2020 at 06:30:36PM +0800, cy_huang wrote:
> > From: ChiYuan Huang
> >
> > Add a devicetree binding documentation for the MT6360 Type-C driver.
> >
> > usb typec: mt6360: Rename DT binding doument from mt6360 to mt636x
> >
> >
On Fri, Aug 28, 2020 at 2:24 AM Jonathan Cameron
wrote:
>
> On Fri, 14 Aug 2020 14:47:20 -0700
> Atish Patra wrote:
>
> > ARM64 numa implementation is generic enough that RISC-V can reuse that
> > implementation with very minor cosmetic changes. This will help both
> > ARM64 and RISC-V in terms
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 005c53447a63cbce10de37406975a34d7bdc8704
commit: 0e4f7f920a5c6bfe5e851e989f27b35a0cc7fb7e tty: serial: msm_serial: Fix
lockup for sysrq and oops
date: 9 months ago
config: arm64-randconfig-s031-20200829
On Thu, Aug 27, 2020 at 04:24:50PM +0300, Jarkko Sakkinen wrote:
> > > + * @arg: userspace pointer to a struct sgx_enclave_create instance
> > > + *
> > > + * Allocate kernel data structures for a new enclave and execute ECREATE
> > > after
> > > + * verifying the correctness of the provided
+config SND_SOC_SC7180
+ tristate "SoC Machine driver for SC7180 boards"
+ depends on SND_SOC_QCOM
this depends is probably not necessary, the code is already in an if case.
+ select SND_SOC_QCOM_COMMON
+ select SND_SOC_LPASS_SC7180
+ select SND_SOC_MAX98357A
Fix min_low_pfn/max_low_pfn build errors for arch/microblaze/: (e.g.)
ERROR: "min_low_pfn" [drivers/rpmsg/virtio_rpmsg_bus.ko] undefined!
ERROR: "min_low_pfn" [drivers/hwtracing/intel_th/intel_th_msu_sink.ko]
undefined!
ERROR: "min_low_pfn" [drivers/hwtracing/intel_th/intel_th_msu.ko]
Fix min_low_pfn/max_low_pfn build errors for arch/ia64/: (e.g.)
ERROR: "max_low_pfn" [drivers/rpmsg/virtio_rpmsg_bus.ko] undefined!
ERROR: "min_low_pfn" [drivers/rpmsg/virtio_rpmsg_bus.ko] undefined!
ERROR: "min_low_pfn" [drivers/hwtracing/intel_th/intel_th_msu.ko] undefined!
ERROR:
On one board I found that:
probe of 5-0028 returned 1 after 259547 usecs
There's no reason to block probe of all other devices on our probe.
Turn on async probe.
Signed-off-by: Douglas Anderson
---
NOTE: I haven't done any analysis of the driver to see _why_ it's so
slow, only that I have
Export min_low_pfn & max_low_pfn in mm/memblock.c to fix build errors
on arch/microblaze/ and arch/ia64/: (e.g.)
ERROR: "max_low_pfn" [drivers/rpmsg/virtio_rpmsg_bus.ko] undefined!
ERROR: "min_low_pfn" [drivers/rpmsg/virtio_rpmsg_bus.ko] undefined!
ERROR: "max_low_pfn"
Change the format of spmi bus device names from:
-
Example: 0-01
to this:
spmi-
Example: spmi0-01
This helps to disambiguate SPMI device regmaps from I2C ones
at /sys/kernel/debug/regmap since I2C devices use a very
similar naming scheme: 0-.
Signed-off-by: David Collins
---
On 8/28/20 4:16 PM, Brian Vazquez wrote:
> On Fri, Aug 28, 2020 at 8:12 AM Randy Dunlap wrote:
>>
>> On 8/28/20 8:09 AM, Sven Joachim wrote:
>>> On 2020-08-27 11:12 -0700, Brian Vazquez wrote:
>>>
I've been trying to reproduce it with your config but I didn't
succeed. I also looked at
The pull request you sent on Fri, 28 Aug 2020 14:03:22 -0600:
> git://git.kernel.dk/linux-block.git tags/io_uring-5.9-2020-08-28
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/24148d8648e37f8c15bedddfa50d14a31a0582c5
Thank you!
--
Deet-doot-dot, I am a bot.
On Thu, Aug 27, 2020 at 06:15:27PM +0200, Borislav Petkov wrote:
> On Thu, Aug 27, 2020 at 04:24:36PM +0300, Jarkko Sakkinen wrote:
> > I have not checked if this passes checkpatch.pl yet, but I would
> > be surprised if that did not pass (obviously I'll check that).
>
> Right, when you're done
On Thu, Aug 27, 2020 at 08:20:51AM -0700, Sean Christopherson wrote:
> On Thu, Aug 27, 2020 at 12:47:04AM -0400, Nathaniel McCallum wrote:
> > > +int main(int argc, char *argv[], char *envp[])
> > > +{
> > > + struct sgx_enclave_exception exception;
> > > + struct vdso_symtab symtab;
>
On 8/28/20 5:25 PM, Peter Zijlstra wrote:
The only pupose of this loop seem to be to find if we have a forceidle;
surely we can avoid that by storing this during the pick.
The idea was to kick each cpu that was force idle. But now, thinking
about it, we just need to kick one as it will pick
On 8/28/20 4:15 PM, Sasha Levin wrote:
On Fri, Aug 28, 2020 at 03:25:11PM -0700, Sowjanya Komatineni wrote:
commit b5a84ecf025a ("mmc: tegra: Add Tegra210 support")
What does this line above represent?
SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK is set incorrectly in above commit
when Tegra210
The probe of rt5682 is pretty slow. A quick measurement shows that it
takes ~650 ms on at least one board. There's no reason to block all
other drivers waiting for this probe to finish. Set the flag to allow
other drivers to probe while we're probing.
Signed-off-by: Douglas Anderson
---
NOTE:
On Fri, Aug 28, 2020 at 8:12 AM Randy Dunlap wrote:
>
> On 8/28/20 8:09 AM, Sven Joachim wrote:
> > On 2020-08-27 11:12 -0700, Brian Vazquez wrote:
> >
> >> I've been trying to reproduce it with your config but I didn't
> >> succeed. I also looked at the file after the preprocessor and it
> >>
On Fri, Aug 28, 2020 at 03:25:11PM -0700, Sowjanya Komatineni wrote:
commit b5a84ecf025a ("mmc: tegra: Add Tegra210 support")
What does this line above represent?
SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK is set for Tegra210 from the
beginning of Tegra210 support in the driver.
Tegra210 SDMMC
From: Stephen Hemminger
Date: Fri, 28 Aug 2020 14:52:03 -0700
> Changing the default range impacts existing users. Since Linux has been doing
> this for so long, I don't think just because a standards body decided to
> reserve
> some space is sufficient justification to do this.
Agreed, there
On Fri, Aug 28, 2020 at 7:00 AM Andrew Lunn wrote:
>
> On Fri, Aug 28, 2020 at 04:19:39AM +0200, Andrew Lunn wrote:
> > When building without CONFIG_OF and W=1, errors are given about unused
> > arrays of match data, because of_match_node is stubbed as a macro. The
> > compile does not see it
Hi,
On Wed, Aug 26, 2020 at 4:05 AM Cheng-Yi Chiang wrote:
>
> +config SND_SOC_SC7180
> + tristate "SoC Machine driver for SC7180 boards"
> + depends on SND_SOC_QCOM
> + select SND_SOC_QCOM_COMMON
> + select SND_SOC_LPASS_SC7180
> + select SND_SOC_MAX98357A
> +
On 8/25/20 6:25 AM, Cornelia Huck wrote:
On Fri, 21 Aug 2020 15:56:03 -0400
Tony Krowiak wrote:
Let's create links between each queue device bound to the vfio_ap device
driver and the matrix mdev to which the queue is assigned. The idea is to
facilitate efficient retrieval of the objects
On Fri, Aug 28, 2020 at 09:24:19PM +0200, Anders Roxell wrote:
> On Fri, 28 Aug 2020 at 15:29, Paul E. McKenney wrote:
> >
> > On Fri, Aug 28, 2020 at 09:37:17AM +0200, Anders Roxell wrote:
> > > On Wed, 26 Aug 2020 at 21:39, Paul E. McKenney wrote:
> > > >
> > > > On Wed, Aug 26, 2020 at
On Fri, 28 Aug 2020 18:54:50 -0400
Steven Rostedt wrote:
> On Fri, 28 Aug 2020 18:49:55 -0400
> Steven Rostedt wrote:
>
> > On Fri, 28 Aug 2020 15:53:06 +0800
> > Wen Gong wrote:
> >
> > > this patch commit id is : 0fc1b09ff1ff404ddf753f5ffa5cd0adc8fdcdc9 which
> > > has upstream.
> > >
On Fri, 28 Aug 2020 18:49:55 -0400
Steven Rostedt wrote:
> On Fri, 28 Aug 2020 15:53:06 +0800
> Wen Gong wrote:
>
> > this patch commit id is : 0fc1b09ff1ff404ddf753f5ffa5cd0adc8fdcdc9 which
> > has upstream.
> >
> > how much size is the per cpu buffer?
> > seems it is initilized in
sprintf does not know the PAGE_SIZE maximum of the temporary buffer
used for outputting sysfs content requests and it's possible to
overrun the buffer length.
Add a generic sysfs_emit mechanism that knows that the size of the
temporary buffer and ensures that no overrun is done.
Signed-off-by:
On Fri, 28 Aug 2020 15:53:06 +0800
Wen Gong wrote:
> this patch commit id is : 0fc1b09ff1ff404ddf753f5ffa5cd0adc8fdcdc9 which
> has upstream.
>
> how much size is the per cpu buffer?
> seems it is initilized in trace_buffered_event_enable,
> it is only 1 page size as below:
> void
Hi Boris,
On Fri, 2020-08-28 at 20:42 +0200, Borislav Petkov wrote:
> On Mon, Aug 24, 2020 at 11:04:12AM -0700, Kyung Min Park wrote:
> > +If the expected flag does not appear in /proc/cpuinfo, things are
> > murkier.
> > +Users need to find out the reason why the flag is missing and find
> > the
In the DWC3 databook, for a device initiated disconnect or bus reset, the
driver is required to send dependxfer commands for any pending transfers.
In addition, before the controller can move to the halted state, the SW
needs to acknowledge any pending events. If the controller is not halted
Hi Jean,
Thanks for the review!
On Mon, 24 Aug 2020 12:32:39 +0200
Jean-Philippe Brucker wrote:
> On Fri, Aug 21, 2020 at 09:35:10PM -0700, Jacob Pan wrote:
> > IOASID is used to identify address spaces that can be targeted by
> > device DMA. It is a system-wide resource that is essential to
On Wed, 26 Aug 2020 09:51:40 +0300, Eugen Hristev wrote:
> Add bindings documentation for Microchip CSI2 Demultiplexer controller.
>
> CSI2DC is a demultiplexer from Synopsys IDI interface specification to
> parallel interface connection or direct memory access.
>
> Signed-off-by: Eugen Hristev
Hello,
syzbot found the following issue on:
HEAD commit:d8be0e12 Add linux-next specific files for 20200824
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=12fa85ee90
kernel config: https://syzkaller.appspot.com/x/.config?x=9ef0a5f95935d447
dashboard
On Tue, 25 Aug 2020 21:35:34 +0200, Krzysztof Kozlowski wrote:
> The i.MX 8QXP DTSes use two compatibles so update the binding to fix
> dtbs_check warnings like:
>
> arch/arm64/boot/dts/freescale/imx8qxp-mek.dt.yaml: serial@5a06:
> compatible: ['fsl,imx8qxp-lpuart',
On Tue, 25 Aug 2020 21:35:30 +0200, Krzysztof Kozlowski wrote:
> DTSes with new i.MX 8M SoCs use two compatibles so update the binding to
> fix dtbs_check warnings like:
>
> arch/arm64/boot/dts/freescale/imx8mn-evk.dt.yaml: efuse@3035:
> compatible:1: 'syscon' was expected
> From
commit b5a84ecf025a ("mmc: tegra: Add Tegra210 support")
SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK is set for Tegra210 from the
beginning of Tegra210 support in the driver.
Tegra210 SDMMC hardware by default uses timeout clock (TMCLK)
instead of SDCLK and this quirk should not be set.
So, this patch
commit 39cb62cb8973 ("arm64: tegra: Add Tegra186 support")
Tegra186 uses separate SDMMC_LEGACY_TM clock for data timeout and
this clock is not enabled currently which is not recommended.
Tegra186 SDMMC advertises 12Mhz as timeout clock frequency in host
capability register and uses it by
commit 5425fb15d8ee ("arm64: tegra: Add Tegra194 chip device tree")
Tegra194 uses separate SDMMC_LEGACY_TM clock for data timeout and
this clock is not enabled currently which is not recommended.
Tegra194 SDMMC advertises 12Mhz as timeout clock frequency in host
capability register.
So, this
commit b5a84ecf025a ("mmc: tegra: Add Tegra210 support")
Tegra210 and later has a separate sdmmc_legacy_tm (TMCLK) used by Tegra
SDMMC hawdware for data timeout to achive better timeout than using
SDCLK and using TMCLK is recommended.
USE_TMCLK_FOR_DATA_TIMEOUT bit in Tegra SDMMC register
commit 742af7e7a0a1 ("arm64: tegra: Add Tegra210 support")
Tegra210 uses separate SDMMC_LEGACY_TM clock for data timeout and
this clock is not enabled currently which is not recommended.
Tegra SDMMC advertises 12Mhz as timeout clock frequency in host
capability register.
So, this clock should
Tegra210/Tegra186/Tegra194 has incorrectly enabled
SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK from the beginning of their support.
Tegra210 and later SDMMC hardware default uses sdmmc_legacy_tm (TMCLK)
all the time for hardware data timeout instead of SDCLK and this TMCLK
need to be kept enabled by
commit b5a84ecf025a ("mmc: tegra: Add Tegra210 support")
Tegra210 and later uses separate SDMMC_LEGACY_TM clock for data
timeout.
So, this patch adds "tmclk" to Tegra sdhci clock property in the
device tree binding.
Fixes: b5a84ecf025a ("mmc: tegra: Add Tegra210 support")
Cc: stable # 4.19
commit 4346b7c7941d ("mmc: tegra: Add Tegra186 support")
SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK is set for Tegra186 from the
beginning of its support in driver.
Tegra186 SDMMC hardware by default uses timeout clock (TMCLK) instead
of SDCLK and this quirk should not be set.
So, this patch remove
On Tue, Aug 25, 2020 at 03:44:40PM +0200, Matthias Schiffer wrote:
> As for I2C and SPI, it now is possible to reserve a fixed index for
> mmc/mmcblk devices.
>
> Signed-off-by: Matthias Schiffer
> ---
>
> v3: new patch
>
> Documentation/devicetree/bindings/mmc/mmc-controller.yaml | 8
On Fri, Aug 28, 2020 at 06:02:25PM -0400, Vineeth Pillai wrote:
[...]
> > Can we please split out this hotplug 'fix' into a separate patch with a
> > coherent changelog.
> Sorry about this. I had posted this as separate patches in v6 list,
> but merged it for v7. Will split it and have details
Hi all,
Commit
ffaab3f87589 ("Documentation/llvm: Improve formatting of commands, variables,
and arguments")
is missing a Signed-off-by from its committer.
--
Cheers,
Stephen Rothwell
pgpNJZWaTdQaG.pgp
Description: OpenPGP digital signature
On Tue, 25 Aug 2020 16:22:06 +0800, Grant Feng wrote:
> The chip enters hardware shutdown when the SDB pin is pulled low.
> The chip releases hardware shutdown when the SDB pin is pulled high.
>
> Signed-off-by: Grant Feng
> ---
> Documentation/devicetree/bindings/leds/leds-is31fl319x.txt | 2
Hi Mike,
On 8/28/20 9:39 AM, Mike Rapoport wrote:
> From: Mike Rapoport
>
> Rework if memory map initialization broke initialization of ARC systems
> with two memory banks. Before these changes, memblock was not aware of
> nodes configuration and the memory map was always allocated from the
>
On 8/28/20 4:55 PM, Peter Zijlstra wrote:
On Fri, Aug 28, 2020 at 03:51:09PM -0400, Julien Desfossez wrote:
+ if (is_idle_task(rq_i->core_pick) && rq_i->nr_running)
+ rq_i->core_forceidle = true;
Did you mean: rq_i->core_pick == rq_i->idle ?
On Fri, Aug 28, 2020 at 06:30:36PM +0800, cy_huang wrote:
> From: ChiYuan Huang
>
> Add a devicetree binding documentation for the MT6360 Type-C driver.
>
> usb typec: mt6360: Rename DT binding doument from mt6360 to mt636x
>
> Signed-off-by: ChiYuan Huang
> ---
>
[-iio list][+kernel list]
On Tue, Aug 25, 2020 at 5:29 PM Gwendal Grignou wrote:
>
> By default, the lightbar commands are set to the
> biggest lightbar command and response. That length is greater than 128
> bytes and may not work on all machines.
> But all EC are probed for lightbar by
On Fri, Aug 28, 2020 at 06:30:36PM +0800, cy_huang wrote:
> From: ChiYuan Huang
>
> Add a devicetree binding documentation for the MT6360 Type-C driver.
>
> usb typec: mt6360: Rename DT binding doument from mt6360 to mt636x
>
> Signed-off-by: ChiYuan Huang
> ---
>
On 8/28/20 4:51 PM, Peter Zijlstra wrote:
cpumask_weigt() is fairly expensive, esp. for something that should
'never' happen.
What exactly is the race here?
We'll update the cpu_smt_mask() fairly early in secondary bringup, but
where does it become a problem?
The moment the new thread
On Mon, 24 Aug 2020 20:04:06 -0700, Chris Healy wrote:
> From: Chris Healy
>
> Add syscon compatibility with Vybrid OCOTP driver binding. This is
> required to access the UID.
>
> Fixes: 623069946952 ("nvmem: Add DT binding documentation for Vybrid
> OCOTP driver")
> Cc: sta...@vger.kernel.org
On Mon, 24 Aug 2020 21:18:17 +0200, Krzysztof Kozlowski wrote:
> Add a binding for the Variscite Symphony evaluation kit board with
> VAR-SOM-MX8MM System on Module.
>
> Signed-off-by: Krzysztof Kozlowski
>
> ---
>
> Changes since v1:
> 1. None
> ---
>
1 - 100 of 1034 matches
Mail list logo
