On Fri 26 Mar 18:13 CDT 2021, Eric Anholt wrote:
> This enables the adreno-specific SMMU path that sets HUPCF so
> (user-managed) page faults don't wedge the GPU.
>
> Signed-off-by: Eric Anholt
Acked-by: Bjorn Andersson
@Will, can you pick this together with the driver patch? (So that they
Hi Kevin,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.12-rc5 next-20210329]
[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 Fri 26 Mar 18:13 CDT 2021, Eric Anholt wrote:
> db820c wants to use the qcom smmu path to get HUPCF set (which keeps
> the GPU from wedging and then sometimes wedging the kernel after a
> page fault), but it doesn't have separate pagetables support yet in
> drm/msm so we can't go all the way
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: Jisheng Zhang
---
arch/arm/mm/ptdump_debugfs.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/arch/arm/mm/ptdump_debugfs.c b/arch/arm/mm/ptdump_debugfs.c
index 8df9afac8d81..318de969ae0f
Hi Doug,
On Mon, Mar 29, 2021 at 07:57:05PM -0700, Doug Anderson wrote:
> On Tue, Mar 16, 2021 at 5:44 PM Doug Anderson wrote:
> > On Tue, Mar 16, 2021 at 2:46 PM Laurent Pinchart wrote:
> > > On Mon, Mar 15, 2021 at 09:25:37AM -0700, Doug Anderson wrote:
> > > > On Sat, Mar 13, 2021 at 1:17 PM
They are not needed after booting, so mark them as __init to move them
to the .init section.
Signed-off-by: Jisheng Zhang
---
arch/arm/mm/dump.c | 4 ++--
arch/arm/mm/ptdump_debugfs.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mm/dump.c
They are not needed after booting, so mark them as __init to move them
to the .init section.
Signed-off-by: Jisheng Zhang
---
arch/arm64/include/asm/ptdump.h | 2 +-
arch/arm64/mm/ptdump.c | 4 ++--
arch/arm64/mm/ptdump_debugfs.c | 2 +-
3 files changed, 4 insertions(+), 4
On Mon, Mar 29, 2021 at 06:01:00PM -0700, Guenter Roeck wrote:
> On 3/29/21 5:21 PM, Jonas Malaco wrote:
> > On Mon, Mar 29, 2021 at 02:53:39PM -0700, Guenter Roeck wrote:
> >> On Mon, Mar 29, 2021 at 05:22:01AM -0300, Jonas Malaco wrote:
> >>> To avoid a spinlock, the driver explores concurrent
On 2021/3/30 9:57, Huang, Ying wrote:
> Hi, Miaohe,
>
> Miaohe Lin writes:
>
>> Hi all,
>> I am investigating the swap code, and I found the below possible race window:
>>
>> CPU 1CPU 2
>> -
On Mon, Mar 29, 2021 at 8:50 PM Peter Zijlstra wrote:
>
> On Mon, Mar 29, 2021 at 08:01:41PM +0800, Guo Ren wrote:
> > u32 a = 0x55aa66bb;
> > u16 *ptr =
> >
> > CPU0 CPU1
> > = =
> > xchg16(ptr, new) while(1)
> >
Currently, the property "ports" is always present. So mark it as true, and
let audio-graph-card.yaml to check it.
Otherwise, warnings similar to the following will be reported:
arch/arm64/boot/dts/renesas/r8a774a1-beacon-rzg2m-kit.dt.yaml: \
sound@ec50: 'ports' does not match any of the
When I do dt_binding_check for all YAML files, below warning is reported:
/root/mainline/Documentation/devicetree/bindings/sound/renesas,rsnd.example.dt.yaml:
sound@ec50: 'dais' is a required property
From schema:
When I do dt_binding_check, below warning is reported:
Documentation/devicetree/bindings/sound/renesas,rsnd.example.dt.yaml: \
sound@ec50: 'dais' is a required property
I looked at all the dts files in the "arch/arm64/boot/dts/renesas/"
directory, I found that all nodes that contain the
Arnd,
> I think Martin is still waiting for a fixed version of the patch, as
> the proposed patch from March 12 only solves the immediate symptom,
> but not the underlying problem of the CommandList structure being
> marked as unaligned. If it gets fixed, the new version should work on
> all
On Tue 23 Mar 2021 at 16:14, Ming Lei wrote:
On some ARCHs, such as aarch64, page size may be 64K, meantime
there may
be lots of CPU cores. relay_open() needs to allocate pages on
each CPU
blktrace, so easily too many pages are taken by blktrace. For
example,
on one ARM64 server: 224 CPU
> On Mar 29, 2021, at 7:04 PM, Andi Kleen wrote:
>
>
>>
>>> No, if these instructions take a #VE then they were executed at CPL=0.
>>> MONITOR
>>> and MWAIT will #UD without VM-Exit->#VE. Same for WBINVD, s/#UD/#GP.
>>
>> Dare I ask about XSETBV?
>
> XGETBV does not cause a #VE, it
Hi,
On Tue, Mar 16, 2021 at 5:44 PM Doug Anderson wrote:
>
> Hi,
>
> On Tue, Mar 16, 2021 at 2:46 PM Laurent Pinchart
> wrote:
> >
> > Hi Doug,
> >
> > On Mon, Mar 15, 2021 at 09:25:37AM -0700, Doug Anderson wrote:
> > > On Sat, Mar 13, 2021 at 1:17 PM Laurent Pinchart wrote:
> > > > On Thu,
Unpreparing and re-preparing a panel can be a really heavy
operation. Panels datasheets often specify something on the order of
500ms as the delay you should insert after turning off the panel
before turning it on again. In addition, turning on a panel can have
delays on the order of 100ms - 200ms
Though I don't have access to any hardware that uses ti-sn65dsi86 and
_doesn't_ provide a "refclk", I believe that we'll have trouble
reading the EDID at bootup in that case. Specifically I believe that
if there's no "refclk" we need the MIPI source clock to be active
before we can successfully
eDP panels won't provide their EDID unless they're powered on. Let's
chain a power-on before we read the EDID. This roughly matches what
was done in 'parade-ps8640.c'.
NOTE: The old code attempted to call pm_runtime_get_sync() before
reading the EDID. While that was enough to power the bridge
Now that we have the patch ("drm/edid: Use the cached EDID in
drm_get_edid() if eDP") we no longer need to maintain our own
cache. Drop this code.
Signed-off-by: Douglas Anderson
---
(no changes since v1)
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 22 +-
1 file changed, 9
Now that we can properly read the EDID for modes there should be no
reason to fallback to the fixed modes that our downstream panel driver
provides us. Let's make that clear by:
- Putting an error message in the logs if we fall back.
- Putting a comment in saying what's going on.
Signed-off-by:
Each time we call drm_get_edid() we:
1. Go out to the bus and ask for the EDID.
2. Cache the EDID.
We can improve this to actually use the cached EDID so that if
drm_get_edid() is called multiple times then we don't need to go out
to the bus over and over again.
In normal DP/HDMI cases reading
We prepared the panel in pre_enable() so we should unprepare it in
post_disable() to match.
This becomes important once we start using pre_enable() and
post_disable() to make sure things are powered on (and then off again)
when reading the EDID.
Signed-off-by: Douglas Anderson
---
(no changes
As of commit 5186421cbfe2 ("drm: Introduce epoch counter to
drm_connector") the drm_get_edid() function calls
drm_connector_update_edid_property() for us. There's no reason for us
to call it again.
Signed-off-by: Douglas Anderson
---
(no changes since v1)
drivers/gpu/drm/bridge/ti-sn65dsi86.c
If we just leave the detect() function as NULL then the upper layers
assume we're always connected. There's no reason for a stub.
Signed-off-by: Douglas Anderson
---
(no changes since v1)
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 12
1 file changed, 12 deletions(-)
diff --git
The register() / attach() for MIPI happen in the bridge's
attach(). That means that the inverse belongs in the bridge's
detach().
Signed-off-by: Douglas Anderson
---
(no changes since v1)
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 15 +--
1 file changed, 9 insertions(+), 6
Let's make the remove() function strictly the reverse of the probe()
function so it's easier to reason about.
NOTES:
- The MIPI calls probably belong in detach() but will be moved in a
separate patch.
- The cached EDID freeing isn't actually part of probe but needs to be
in remove to avoid
A random comment inside a function had "/**" in front of it. That
doesn't make sense. Remove.
Signed-off-by: Douglas Anderson
---
(no changes since v1)
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
The clock framework makes it simple to deal with an optional clock.
You can call clk_get_optional() and if the clock isn't specified it'll
just return NULL without complaint. It's valid to pass NULL to
enable/disable/prepare/unprepare. Let's make use of this to simplify
things a tiny bit.
The drm_bridge_chain_pre_enable() is not the proper opposite of
drm_bridge_chain_post_disable(). It continues along the chain to
_before_ the starting bridge. Let's fix that.
Fixes: 05193dc38197 ("drm/bridge: Make the bridge chain a double-linked list")
Signed-off-by: Douglas Anderson
---
(no
The primary goal of this series is to try to properly fix EDID reading
for eDP panels using the ti-sn65dsi86 bridge.
Previously we had a patch that added EDID reading but it turned out
not to work at bootup. This caused some extra churn at bootup as we
tried (and failed) to read the EDID several
Dear Daniel,
Kindly ping.
Can this patch be merged? Or any comment?
BR,
Michael
On Tue, 2020-12-29 at 13:08 +0800, Michael Kao wrote:
> From: brian-sy yang
>
> Slab OOB issue is scanned by KASAN in cpu_power_to_freq().
> If power is limited below the power of OPP0 in EM table,
> it will cause
While device_add() will happen to catch dev_set_name() failures it is a
broken pattern to follow given that the core may try to fall back to a
different name.
Add explicit checking for dev_set_name() failures to be cleaned up by
put_device(). Skip cdev_device_add() and proceed directly to
There is no power management of cxl virtual devices, disable
device-power-management and runtime-power-management to prevent
userspace from growing expectations of those attributes appearing. They
can be added back in the future if needed.
Reviewed-by: Ben Widawsky
Signed-off-by: Dan Williams
The percpu_ref to gate whether cxl_memdev_ioctl() is free to use the
driver context (@cxlm) to issue I/O is overkill, implemented incorrectly
(missing a device reference before accessing the percpu_ref), and the
complexities of shutting down a percpu_ref contributed to a bug in the
error unwind in
While none the CXL sysfs attributes are threatening to overrun a
PAGE_SIZE of output, it is good form to use the recommended helpers.
Fixes: b39cb1052a5c ("cxl/mem: Register CXL memX devices")
Reported-by: Jason Gunthorpe
Reviewed-by: Ben Widawsky
Reviewed-by: Jason Gunthorpe
Link:
Changes since v1: [1]
- switch percpu_ref to srcu (Jason)
- introduce cxl_memdev_alloc() (Jason)
[1]:
http://lore.kernel.org/r/161661970558.1721612.10441826898835759137.st...@dwillia2-desk3.amr.corp.intel.com
---
A small collection of fixes mostly inspired by Jason's recognition of
This patch adds support for XDP_TX action which enables XDP program to
transmit back received frames.
This patch has been tested with the "xdp2" app located in samples/bpf
dir. The DUT receives burst traffic packet generated using pktgen script
'pktgen_sample03_burst_single_flow.sh'.
Lee,
> Commit b43abcbbd5b1 ("scsi: fnic: Ratelimit printks to avoid looding
> when vlan is not set by the switch.i") added printk_ratelimit() in
> front of a couple of debug-mode messages, to reduce logging overrun
> when debugging the driver.
Applied to 5.13/scsi-staging, thanks!
--
Martin
This patch adds the support of XDP_REDIRECT to another remote cpu for
further action. It also implements ndo_xdp_xmit ops, enabling the driver
to transmit packets forwarded to it by XDP program running on another
interface.
This patch has been tested using "xdp_redirect_cpu" for XDP_REDIRECT
+
SPH functionality splits header and payload according to split mode and
offsef fields (SPLM and SPLOFST). It is beneficials for Linux network
stack RX processing however it adds a lot of complexity in XDP
processing.
So, this patch makes the split-header (SPH) capability of the controller
is
This patch adds the initial XDP support to stmmac driver. It supports
XDP_PASS, XDP_DROP and XDP_ABORTED actions. Upcoming patches will add
support for XDP_TX and XDP_REDIRECT.
To support XDP headroom, this patch adds page_offset into RX buffer and
change the dma_sync_single_for_device|cpu(). The
This patch organizes TX tail pointer update into a new function called
stmmac_flush_tx_descriptors() so that we can reuse it in stmmac_xmit(),
stmmac_tso_xmit() and up-coming XDP implementation.
Changes to v2:
- Fix for warning: unused variable ‘desc_size’
Certain platform likes Intel mGBE has independent hardware IRQ resources
for TX and RX DMA operation. In preparation to support XDP TX, we add IRQ
affinity hint to group both RX and TX queue of the same queue ID to the
same CPU.
Changes in v2:
- IRQ affinity hint need to set to null before IRQ
Hi,
This is the v2 patch series for adding XDP support to stmmac driver.
Summary of the changes in v2:
1/6: Move IRQ affinity hint from dwmac-intel.c into stmmac_main.c inside
stmmac_request_irq_multi_msi() and clear the IRQ affinity hint in
stmmac_free_irq().
Tested the patch
On Thu, Mar 4, 2021 at 12:29 AM Linus Walleij wrote:
>
> Hi Brad,
>
> thanks for your patch!
>
> On Thu, Mar 4, 2021 at 4:42 AM Brad Larson wrote:
>
> > This GPIO driver is for the Pensando Elba SoC which
> > provides control of four chip selects on two SPI busses.
> >
> > Signed-off-by: Brad
Cross time-stamping mechanism used in certain instance of Intel mGbE
may run at different clock frequency in comparison to the clock
frequency used by processor, so we introduce cross T/S frequency
adjustment to ensure TSC calculation is correct when processor got the
cross time-stamps.
Hi,
Thanks for reporting this issue, I'll check and add a fix to handle defer probe.
Best regards,
Alice Guo
> -Original Message-
> From: Dominique MARTINET
> Sent: 2021年3月29日 17:09
> To: Alice Guo ; Shawn Guo ;
> Krzysztof Kozlowski
> Cc: robh...@kernel.org;
Hi,
On Mon, 2021-03-29 at 17:24 +0200, Matthias Brugger wrote:
>
> On 15/03/2021 18:35, Hsin-Hsiung Wang wrote:
> > From: Wen Su
> >
> > add PMIC MT6359 related nodes which is for MT6779 platform
> >
> > Signed-off-by: Wen Su
> > Signed-off-by: Hsin-Hsiung Wang
> > ---
> > changes since v5:
On 03/30/2021 09:48 AM, Jiaxun Yang wrote:
On Mon, Mar 29, 2021, at 3:15 PM, Qing Zhang wrote:
When using the Loongson-3A4000 machine for serial port debugging,
there is no /dev/ttyUSB* output, which makes the serial port unavailable,
For convenience, we open this configuration.
fdefs. It errors out at compile-time with this
> > config: https://sr71.net/~dave/intel/config-mmotm-20210311
>
> It seems that mmotm still has v5.
> v6 (this one) fixed that up. I basically moved the code out of
> MEMORY_HOTPLUG #ifdefs.
>
> I could not reproduce your error on v6.
I can reproduce this with next-20210329.
.config attached.
config-for-osal.xz
Description: application/xz
On Tue, Mar 30, 2021 at 7:24 AM Mike Kravetz wrote:
>
> free_pool_huge_page was called with hugetlb_lock held. It would remove
> a hugetlb page, and then free the corresponding pages to the lower level
> allocators such as buddy. free_pool_huge_page was called in a loop to
> remove hugetlb
From: dillon min
To use additional properties 'bluetooth' on serial, need replace false with
'type: object' for 'additionalProperties' to make it as a node, else will
run into dtbs_check warnings.
'arch/arm/boot/dts/stm32h750i-art-pi.dt.yaml: serial@40004800:
'bluetooth' does not match any of
From: dillon min
The STM32H750 is a Cortex-M7 MCU running at 480MHz
and containing 128KBytes internal flash, 1MiB SRAM.
Signed-off-by: dillon min
---
v7: no changes
arch/arm/mach-stm32/board-dt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-stm32/board-dt.c
From: dillon min
This patchset has following changes:
- introduce stm32h750.dtsi to support stm32h750 value line
- add stm32h750i-art-pi.dtb (arch/arm/boot/dts/Makefile)
- add dts binding usart3 for bt, uart4 for console
usart3/uart4 pinctrl in stm32h7-pinctrl.dtsi
usart3/uart4 register in
From: dillon min
This patch is intend to add support stm32h750 value line,
just add stm32h7-pinctrl.dtsi for extending, with following changes:
- rename stm32h743-pinctrl.dtsi to stm32h7-pinctrl.dtsi
- move compatible string "st,stm32h743-pinctrl" from stm32h7-pinctrl.dtsi
to
From: dillon min
Art-pi based on stm32h750xbh6, with following resources:
-8MiB QSPI flash
-16MiB SPI flash
-32MiB SDRAM
-AP6212 wifi, bt, fm
detail information can be found at:
https://art-pi.gitee.io/website/
Signed-off-by: dillon min
Acked-by: Rob Herring
---
v7: no changes
From: dillon min
This patchset intend to add art-pi board support, this board developed
by rt-thread(https://www.rt-thread.org/).
Board resources:
8MiB QSPI flash
16MiB SPI flash
32MiB SDRAM
AP6212 wifi,bt,fm comb
sw context:
- as stm32h750 just has 128k bytes internal flash, so running a fw
From: dillon min
This patchset add support for soc stm32h750, stm32h750 has mirror
different from stm32h743
itemstm32h743 stm32h750
flash size: 2MiB 128KiB
adc:none 3
crypto-hash:none aes/hamc/des/tdes/md5/sha
detail information
On Mon, Mar 29, 2021 at 8:58 AM Mark Brown wrote:
>
> On Sun, Mar 28, 2021 at 06:59:28PM -0700, Brad Larson wrote:
>
> > @@ -56,7 +56,7 @@ struct dw_spi_mscc {
> > /*
> > * The Designware SPI controller (referred to as master in the
> > documentation)
> > * automatically deasserts chip
Hi, Eric, Oleg
Any comment?
>From the previous discussions, i think this change is necessary, but
we need to confirm that move the decrement of signal->live is a
safe.Here are some of my considerations
There are three places that are going to be called besides do_exit().
1.
On Mon, Mar 29, 2021 at 9:56 PM Arnd Bergmann wrote:
>
> On Mon, Mar 29, 2021 at 2:52 PM Guo Ren wrote:
> >
> > On Mon, Mar 29, 2021 at 7:31 PM Peter Zijlstra wrote:
> > >
> > > On Mon, Mar 29, 2021 at 01:16:53PM +0200, Peter Zijlstra wrote:
> > > > Anyway, an additional 'funny' is that I
Quoting Dario Binacchi (2021-03-29 09:42:17)
>
> As reported by the TI spruh73x RM, MPU and LCD modules support spread
> spectrum clocking (SSC) on their output clocks. SSC is used to spread
> the spectral peaking of the clock to reduce any electromagnetic
> interference (EMI) that may be caused
There's no need to declare a list and then init it manually,
just use the LIST_HEAD() macro.
Signed-off-by: Shixin Liu
---
drivers/isdn/mISDN/dsp_core.c | 7 ++-
drivers/isdn/mISDN/l1oip_core.c | 4 +---
2 files changed, 3 insertions(+), 8 deletions(-)
diff --git
spinlock can be initialized automatically with DEFINE_SPINLOCK()
rather than explicitly calling spin_lock_init().
Changelog:
>From v1:
1. fix the mistake reported by kernel test robot.
Signed-off-by: Shixin Liu
---
drivers/isdn/hardware/mISDN/hfcmulti.c | 7 ++-
> From: Jason Gunthorpe
> Sent: Tuesday, March 30, 2021 12:32 AM
> > In terms of usage for guest SVA, an ioasid_set is mostly tied to a host mm,
> > the use case is as the following:
>
> From that doc:
>
> It is imperative to enforce
> VM-IOASID ownership such that a malicious guest cannot
Quoting Dario Binacchi (2021-03-29 09:42:18)
> Replace _omap3_noncore_dpll_program with omap3_noncore_dpll_program.
>
> Signed-off-by: Dario Binacchi
> ---
Reviewed-by: Stephen Boyd
Hi David,
On 2021/3/29 18:09, David Laight wrote:
From: Xiaofei Tan
Sent: 27 March 2021 07:46
Replace __attribute__((packed)) by __packed following the
advice of checkpatch.pl.
Signed-off-by: Xiaofei Tan
---
drivers/acpi/acpi_fpdt.c | 6 +++---
1 file changed, 3 insertions(+), 3
On Tue, Mar 30, 2021 at 7:24 AM Mike Kravetz wrote:
>
> The helper routine hstate_next_node_to_alloc accesses and modifies the
> hstate variable next_nid_to_alloc. The helper is used by the routines
> alloc_pool_huge_page and adjust_pool_surplus. adjust_pool_surplus is
> called with
Quoting Dario Binacchi (2021-03-18 10:26:23)
> Replace _omap3_noncore_dpll_program with omap3_noncore_dpll_program.
>
> Signed-off-by: Dario Binacchi
> ---
Reviewed-by: Stephen Boyd
On Tue, Mar 30, 2021 at 7:24 AM Mike Kravetz wrote:
>
> With the introduction of remove_hugetlb_page(), there is no need for
> update_and_free_page to hold the hugetlb lock. Change all callers to
> drop the lock before calling.
>
> With additional code modifications, this will allow loops which
The Intel VT-d driver checks wrong register to report snoop capablility
when using first level page table for GPA to HPA translation. This might
lead the IOMMU driver to say that it supports snooping control, but in
reality, it does not. Fix this by always setting PASID-table-entry.PGSNP
whenever
On Mon, Mar 29, 2021 at 6:44 AM Linus Walleij wrote:
>
> On Mon, Mar 29, 2021 at 4:00 AM Brad Larson wrote:
>
> > New drivers should include instead
> > of legacy .
> >
> > Signed-off-by: Brad Larson
>
> Fold into patch 1 as indicated by Greg.
>
> Yours,
> Linus Walleij
Yes, thanks for the
On Sun, Mar 28, 2021 at 11:48 PM Greg KH wrote:
>
> On Sun, Mar 28, 2021 at 06:59:38PM -0700, Brad Larson wrote:
> > New drivers should include instead
> > of legacy .
> >
> > Signed-off-by: Brad Larson
> > ---
> > drivers/gpio/gpio-elba-spics.c | 3 +--
> > 1 file changed, 1 insertion(+), 2
On 3/29/21 6:20 PM, Song Bao Hua (Barry Song) wrote:
>
>
>> -Original Message-
>> From: Mike Kravetz [mailto:mike.krav...@oracle.com]
>> Sent: Tuesday, March 30, 2021 12:24 PM
>> To: linux...@kvack.org; linux-kernel@vger.kernel.org
>> Cc: Roman Gushchin ; Michal Hocko ; Shakeel
>> Butt
named 'ttu_regs'
2608 | odm_pipe->ttu_regs.min_ttu_vblank = MAX_TTU;
| ^~
Caused by commit
752106f5c5cd ("drm/amd/display: Set max TTU on DPG enable")
CONFIG_DRM_AMD_DC_DCN is not set in this build.
I have used the amdgpu tree from next-20210329 for today
From: Oliver Neukum
Until very recently, the usbnet framework only had support functions
for devices which reported the link speed by explicitly querying the
PHY over a MDIO interface. However, the cdc_ncm devices send
notifications when the link state or link speeds change and do not
expose the
From: Grant Grundler
Until very recently, the usbnet framework only had support functions
for devices which reported the link speed by explicitly querying the
PHY over a MDIO interface. However, the cdc_ether devices send
notifications when the link state or link speeds change and do not
expose
From: Oliver Neukum
The old method for reporting link speed assumed a driver uses the
generic phy (mii) MDIO read/write functions. CDC devices don't
expose the phy.
Add a primitive internal version reporting back directly what
the CDC notification/status operations recorded.
v2: rebased on
From: Oliver Neukum
The generic functions assumed devices provided an MDIO interface (accessed
via older mii code, not phylib). This is true only for genuine ethernet.
Devices with a higher level of abstraction or based on different
technologies do not have MDIO. To support this case, first
This series introduces support for USB network devices that report
speed as a part of their protocol, not emulating an MII to be accessed
over MDIO.
v2: rebased on recent upstream changes
v3: incorporated hints on naming and comments
v4: fix misplaced hunks; reword some commit messages;
add
Name the GPIOs to help userspace work with them. The names describe the
functionality the lines provide, not the net or ball name. This makes it
easier to share userspace code across different systems and makes the
use of the lines more obvious.
Signed-off-by: Nichole Wang
---
Eric Biggers writes:
> On Tue, Mar 30, 2021 at 02:12:40AM +0530, Shreeya Patel wrote:
>> diff --git a/fs/unicode/Kconfig b/fs/unicode/Kconfig
>> index 2c27b9a5cd6c..ad4b837f2eb2 100644
>> --- a/fs/unicode/Kconfig
>> +++ b/fs/unicode/Kconfig
>> @@ -2,13 +2,26 @@
>> #
>> # UTF-8 normalization
>>
On Tue, Mar 30, 2021 at 10:03 AM Wan Jiabing wrote:
>
> struct mem_cgroup is declared twice. One has been declared
> at forward struct declaration. Remove the duplicate.
>
> Signed-off-by: Wan Jiabing
Reviewed-by: Muchun Song
Thanks.
> ---
> include/linux/memcontrol.h | 2 --
> 1 file
On 3/29/21 10:06 PM, Davidlohr Bueso wrote:
It's a lot more intuitive to have it in the locking section of the kernel
hacking part rather than under "General architecture-dependent options".
Signed-off-by: Davidlohr Bueso
---
arch/Kconfig | 9 -
lib/Kconfig.debug | 9 +
Improve the channel handling state machine such that all commands
go through a common function and a validation process to ensure
that the state machine is not violated in any way and adheres to
the MHI specification. Using this common function allows MHI to:
1. Fail early if device is in a bad
On Mon, Mar 29, 2021 at 9:01 AM Mark Brown wrote:
>
> On Sun, Mar 28, 2021 at 06:59:35PM -0700, Brad Larson wrote:
> > Add new vendor Pensando Systems Elba SoC compatible
> > string and convert to json-schema.
>
> These are two unrelated changes and should be separate patches, again as
> covered
If a channel was explicitly stopped but not reset and a driver
remove is issued, clean up the channel context such that it is
reflected on the device. This move is useful if a client driver
module is unloaded or a device crash occurs with the host having
placed the channel in a stopped state.
Add support to allow sending the STOP channel command. If a
client driver would like to STOP a channel and have the device
retain the channel context instead of issuing a RESET to it and
clearing the context, this would provide support for it after
the ability to send this command is exposed to
When clearing up the channel context after client drivers are
done using channels, the configuration is currently not being
reset entirely. Ensure this is done to appropriately handle
issues where clients unaware of the context state end up calling
functions which expect a context.
Signed-off-by:
MHI specification shows a state machine with support for STOP channel command
and the validity of certain state transitions. MHI host currently does not
provide any mechanism to stop a channel and restart it without resetting it.
There are also times when the device moves on to a different
The __mhi_unprepare_channel() API does not require the __ prefix.
Get rid of it and make the internal function consistent with the
other function names.
Signed-off-by: Bhaumik Bhatt
Reviewed-by: Manivannan Sadhasivam
Reviewed-by: Hemant Kumar
---
drivers/bus/mhi/core/main.c | 10 +-
1
The mhi_prepare_for_transfer() and mhi_unprepare_from_transfer()
APIs could use better explanation. Add details on what MHI does
when these APIs are used.
Signed-off-by: Bhaumik Bhatt
Reviewed-by: Hemant Kumar
Reviewed-by: Manivannan Sadhasivam
---
include/linux/mhi.h | 18 --
A client can attempt to unprepare certain channels for transfer even
after the execution environment they are supposed to run in has changed.
In the event that happens, the device need not be notified of the reset
and the host can proceed with clean up for the channel context and
memory allocated
On 3/29/2021 3:20 PM, John Stultz wrote:
> On Mon, Mar 29, 2021 at 3:15 PM Wesley Cheng wrote:
>>
>>
>>
>> On 3/19/2021 4:09 PM, Thinh Nguyen wrote:
>>> Wesley Cheng wrote:
On 3/8/2021 10:33 PM, Wesley Cheng wrote:
>
>
> On 3/8/2021 7:05 PM, Thinh Nguyen wrote:
Remove unused bpf_load_pointer function in filter.h
Signed-off-by: He Fengqing
---
include/linux/filter.h | 9 -
1 file changed, 9 deletions(-)
diff --git a/include/linux/filter.h b/include/linux/filter.h
index eecfd82db648..9a09547bc7ba 100644
--- a/include/linux/filter.h
+++
On 2021/3/30 7:23, Mike Kravetz wrote:
> With the introduction of remove_hugetlb_page(), there is no need for
> update_and_free_page to hold the hugetlb lock. Change all callers to
> drop the lock before calling.
>
> With additional code modifications, this will allow loops which decrease
> the
It's a lot more intuitive to have it in the locking section of the kernel
hacking part rather than under "General architecture-dependent options".
Signed-off-by: Davidlohr Bueso
---
arch/Kconfig | 9 -
lib/Kconfig.debug | 9 +
2 files changed, 9 insertions(+), 9
On Tue, Mar 23, 2021 at 04:14:38PM +0800, Ming Lei wrote:
> blktrace may pass big trace buffer size via '-b', meantime the system
> may have lots of CPU cores, so too much memory can be allocated for
> blktrace.
>
> The 1st patch shutdown bltrace in blkdev_close() in case of task
> exiting, for
101 - 200 of 2417 matches
Mail list logo
