t we've seen occurrences. Normally when other
external things have gone horribly wrong.
Ivan can clarify as to what's been seen on AMD platforms regarding the
infinite loop for patch one. This was also tested on bare metal
hardware. Injection of the #UD within patch 2 may be debatable but I
believe Ivan has some more data from experiments backing this up.
Best regards,
Jack
On Wed, Apr 10, 2024 at 9:51 AM Jonathan Cameron
wrote:
>
> On Tue, 9 Apr 2024 12:02:31 -0700
> "Ho-Ren (Jack) Chuang" wrote:
>
> > Hi Jonathan,
> >
> > On Tue, Apr 9, 2024 at 9:12 AM Jonathan Cameron
> > wrote:
> > >
> > > On Fr
On Tue, Apr 9, 2024 at 7:33 PM Huang, Ying wrote:
>
> "Ho-Ren (Jack) Chuang" writes:
>
> > On Fri, Apr 5, 2024 at 7:03 AM Jonathan Cameron
> > wrote:
> >>
> >> On Fri, 5 Apr 2024 00:07:06 +
> >> "Ho-Ren (Jack) Chuang"
On Tue, Apr 9, 2024 at 2:50 PM Andrew Morton wrote:
>
> On Tue, 9 Apr 2024 12:00:06 -0700 "Ho-Ren (Jack) Chuang"
> wrote:
>
> > Hi Jonathan,
> >
> > On Fri, Apr 5, 2024 at 6:56 AM Jonathan Cameron
> > wrote:
> > >
> > > On Fri
Hi Jonathan,
On Tue, Apr 9, 2024 at 9:12 AM Jonathan Cameron
wrote:
>
> On Fri, 5 Apr 2024 15:43:47 -0700
> "Ho-Ren (Jack) Chuang" wrote:
>
> > On Fri, Apr 5, 2024 at 7:03 AM Jonathan Cameron
> > wrote:
> > >
> > > On Fri, 5 Apr 202
Hi Jonathan,
On Fri, Apr 5, 2024 at 6:56 AM Jonathan Cameron
wrote:
>
> On Fri, 5 Apr 2024 00:07:05 +
> "Ho-Ren (Jack) Chuang" wrote:
>
> > Since different memory devices require finding, allocating, and putting
> > memory types, these common
On Fri, Apr 5, 2024 at 7:03 AM Jonathan Cameron
wrote:
>
> On Fri, 5 Apr 2024 00:07:06 +
> "Ho-Ren (Jack) Chuang" wrote:
>
> > The current implementation treats emulated memory devices, such as
> > CXL1.1 type3 memory, as normal DRAM when
managed,
a default memory type is created for storing all memory types that are
not initialized by device drivers and as a fallback.
Signed-off-by: Ho-Ren (Jack) Chuang
Signed-off-by: Hao Xiang
Reviewed-by: "Huang, Ying"
---
mm/memory-ti
Since different memory devices require finding, allocating, and putting
memory types, these common steps are abstracted in this patch,
enhancing the scalability and conciseness of the code.
Signed-off-by: Ho-Ren (Jack) Chuang
Reviewed-by: "Huang, Ying"
---
drivers/dax/kmem.c
*
https://lore.kernel.org/lkml/20240312061729.1997111-1-horenchu...@bytedance.com/T/#u
-v1:
*
https://lore.kernel.org/lkml/20240301082248.3456086-1-horenchu...@bytedance.com/T/#u
Ho-Ren (Jack) Chuang (2):
memory tier: dax/kmem: introduce an abstract layer for finding,
allocating, and pu
nice per character
> ruler at the top of the window.
>
> I wonder if you have a different tab indent size? The kernel uses 8
> characters. It might explain the few other odd indents if perhaps
> you have it at 4 in your editor?
>
> https://www.kernel.org/doc/html/v4.10/process/coding-style.html
>
Got it. I was using tab=4. I will change to 8. Thanks!
> Jonathan
>
> >
> > > > + * initialized.
> > > > + */
> > > > + continue;
> > > > +
> > > > memtier = set_node_memory_tier(node);
> > > > if (IS_ERR(memtier))
> > > > /*
> > >
> >
> >
>
--
Best regards,
Ho-Ren (Jack) Chuang
莊賀任
ers with smaller adistance
> >* than default DRAM tier.
> >*/
> > - default_dram_type = alloc_memory_type(MEMTIER_ADISTANCE_DRAM);
> > + default_dram_type = mt_find_alloc_memory_type(MEMTIER_ADISTANCE_DRAM,
> > +
> > &default_memory_types);
>
> Unusual indenting. Align with just after (
>
Aligning with "(" will exceed 100 columns. Would that be acceptable?
> > if (IS_ERR(default_dram_type))
> > panic("%s() failed to allocate default DRAM tier\n",
> > __func__);
> >
> > @@ -868,6 +921,14 @@ static int __init memory_tier_init(void)
> >* types assigned.
> >*/
> > for_each_node_state(node, N_MEMORY) {
> > + if (!node_state(node, N_CPU))
> > + /*
> > + * Defer memory tier initialization on CPUless numa
> > nodes.
> > + * These will be initialized after firmware and
> > devices are
>
> I think this wraps at just over 80 chars. Seems silly to wrap so tightly and
> not
> quite fit under 80. (this is about 83 chars.
>
I can fix this.
I have a question. From my patch, this is <80 chars. However,
in an email, this is >80 chars. Does that mean we need to
count the number of chars in an email, not in a patch? Or if I
missed something? like vim configuration or?
> > + * initialized.
> > + */
> > + continue;
> > +
> > memtier = set_node_memory_tier(node);
> > if (IS_ERR(memtier))
> > /*
>
--
Best regards,
Ho-Ren (Jack) Chuang
莊賀任
Hi Jonathan,
Thanks for your feedback. I will fix them (inlined) in the next V11.
No worries, it's never too late!
On Wed, Apr 3, 2024 at 9:52 AM Jonathan Cameron
wrote:
>
> On Tue, 2 Apr 2024 00:17:37 +
> "Ho-Ren (Jack) Chuang" wrote:
>
> > Since differe
managed,
a default memory type is created for storing all memory types that are
not initialized by device drivers and as a fallback.
Signed-off-by: Ho-Ren (Jack) Chuang
Signed-off-by: Hao Xiang
Reviewed-by: "Huang, Ying"
---
include/linux/memory-tiers.h | 5 +-
mm/memo
Since different memory devices require finding, allocating, and putting
memory types, these common steps are abstracted in this patch,
enhancing the scalability and conciseness of the code.
Signed-off-by: Ho-Ren (Jack) Chuang
Reviewed-by: "Huang, Ying"
---
drivers/dax/kmem.c
40312061729.1997111-1-horenchu...@bytedance.com/T/#u
-v1:
*
https://lore.kernel.org/lkml/20240301082248.3456086-1-horenchu...@bytedance.com/T/#u
Ho-Ren (Jack) Chuang (2):
memory tier: dax/kmem: introduce an abstract layer for finding,
allocating, and putting memory types
memory tier: create
Hi SeongJae,
On Mon, Apr 1, 2024 at 11:27 AM Ho-Ren (Jack) Chuang
wrote:
>
> Hi SeongJae,
>
> On Sun, Mar 31, 2024 at 12:09 PM SeongJae Park wrote:
> >
> > Hi Ho-Ren,
> >
> > On Fri, 29 Mar 2024 05:33:52 + "Ho-Ren (Jack) Chuang"
> > wro
Hi SeongJae,
On Sun, Mar 31, 2024 at 12:09 PM SeongJae Park wrote:
>
> Hi Ho-Ren,
>
> On Fri, 29 Mar 2024 05:33:52 +0000 "Ho-Ren (Jack) Chuang"
> wrote:
>
> > Since different memory devices require finding, allocating, and putting
> > memory types, t
managed,
a default memory type is created for storing all memory types that are
not initialized by device drivers and as a fallback.
Signed-off-by: Ho-Ren (Jack) Chuang
Signed-off-by: Hao Xiang
Reviewed-by: "Huang, Ying"
---
mm/memory-ti
Since different memory devices require finding, allocating, and putting
memory types, these common steps are abstracted in this patch,
enhancing the scalability and conciseness of the code.
Signed-off-by: Ho-Ren (Jack) Chuang
Reviewed-by: "Huang, Ying"
---
drivers/dax/kmem.c
://lore.kernel.org/lkml/20240312061729.1997111-1-horenchu...@bytedance.com/T/#u
-v1:
*
https://lore.kernel.org/lkml/20240301082248.3456086-1-horenchu...@bytedance.com/T/#u
Ho-Ren (Jack) Chuang (2):
memory tier: dax/kmem: introduce an abstract layer for finding,
allocating, and putting memory types
memo
On Thu, Mar 28, 2024 at 5:59 PM Huang, Ying wrote:
>
> "Ho-Ren (Jack) Chuang" writes:
>
> > The current implementation treats emulated memory devices, such as
> > CXL1.1 type3 memory, as normal DRAM when they are emulated as normal memory
> > (E820_TYPE_RAM).
Since different memory devices require finding, allocating, and putting
memory types, these common steps are abstracted in this patch,
enhancing the scalability and conciseness of the code.
Signed-off-by: Ho-Ren (Jack) Chuang
Reviewed-by: "Huang, Ying"
---
drivers/dax/kmem.c
managed,
a default memory type is created for storing all memory types that are
not initialized by device drivers and as a fallback.
Signed-off-by: Ho-Ren (Jack) Chuang
Signed-off-by: Hao Xiang
Reviewed-by: "Huang, Ying"
---
mm/memory-ti
c_memory_type()
* Use the expected way to use set_node_memory_tier instead of modifying it
*
https://lore.kernel.org/lkml/20240312061729.1997111-1-horenchu...@bytedance.com/T/#u
-v1:
*
https://lore.kernel.org/lkml/20240301082248.3456086-1-horenchu...@bytedance.com/T/#u
Ho-Ren (Jack) Chuang
e expected way to use set_node_memory_tier instead of modifying it
*
https://lore.kernel.org/lkml/20240312061729.1997111-1-horenchu...@bytedance.com/T/#u
-v1:
*
https://lore.kernel.org/lkml/20240301082248.3456086-1-horenchu...@bytedance.com/T/#u
Ho-Ren (Jack) Chuang (2):
memory tier: dax/kme
On Wed, Mar 27, 2024 at 6:37 PM Huang, Ying wrote:
>
> "Ho-Ren (Jack) Chuang" writes:
>
> [snip]
>
> > @@ -655,6 +672,34 @@ void mt_put_memory_types(struct list_head
> > *memory_types)
> > }
> > EXPORT_SYMBOL_GPL(mt_put_memory_types);
>
managed,
a default memory type is created for storing all memory types that are
not initialized by device drivers and as a fallback.
Signed-off-by: Ho-Ren (Jack) Chuang
Signed-off-by: Hao Xiang
---
mm/memory-tiers.c | 94 +++
1 file changed, 78
Since different memory devices require finding, allocating, and putting
memory types, these common steps are abstracted in this patch,
enhancing the scalability and conciseness of the code.
Signed-off-by: Ho-Ren (Jack) Chuang
---
drivers/dax/kmem.c | 20 ++--
include
97111-1-horenchu...@bytedance.com/T/#u
-v1:
*
https://lore.kernel.org/lkml/20240301082248.3456086-1-horenchu...@bytedance.com/T/#u
Ho-Ren (Jack) Chuang (2):
memory tier: dax/kmem: introduce an abstract layer for finding,
allocating, and putting memory types
memory tier: create CPUless memory tie
On Tue, Mar 26, 2024 at 10:52 PM Huang, Ying wrote:
>
> "Ho-Ren (Jack) Chuang" writes:
>
> > The current implementation treats emulated memory devices, such as
> > CXL1.1 type3 memory, as normal DRAM when they are emulated as normal memory
> > (E820_TYPE_
`
Because an error path was not handled properly in `mt_perf_to_adistance`,
unlock before returning the error.
Signed-off-by: Ho-Ren (Jack) Chuang
Signed-off-by: Hao Xiang
---
mm/memory-tiers.c | 85 +++
1 file changed, 72 insertions(+), 13 deletions
Since different memory devices require finding, allocating, and putting
memory types, these common steps are abstracted in this patch,
enhancing the scalability and conciseness of the code.
Signed-off-by: Ho-Ren (Jack) Chuang
---
drivers/dax/kmem.c | 20 ++--
include
g it
*
https://lore.kernel.org/lkml/20240312061729.1997111-1-horenchu...@bytedance.com/T/#u
-v1:
*
https://lore.kernel.org/lkml/20240301082248.3456086-1-horenchu...@bytedance.com/T/#u
Ho-Ren (Jack) Chuang (2):
memory tier: dax/kmem: introduce an abstract layer for finding,
allocating, a
On Mon, Mar 25, 2024 at 8:08 PM Huang, Ying wrote:
>
> "Ho-Ren (Jack) Chuang" writes:
>
> > On Fri, Mar 22, 2024 at 1:41 AM Huang, Ying wrote:
> >>
> >> "Ho-Ren (Jack) Chuang" writes:
> >>
> >> > The current implementat
On Fri, Mar 22, 2024 at 1:41 AM Huang, Ying wrote:
>
> "Ho-Ren (Jack) Chuang" writes:
>
> > The current implementation treats emulated memory devices, such as
> > CXL1.1 type3 memory, as normal DRAM when they are emulated as normal memory
> > (E820_TYPE_RAM).
managed,
a default memory type is created for storing all memory types that are
not initialized by device drivers and as a fallback.
Signed-off-by: Ho-Ren (Jack) Chuang
Signed-off-by: Hao Xiang
---
mm/memory-tiers.c | 73 ---
1 file changed, 63
Since different memory devices require finding, allocating, and putting
memory types, these common steps are abstracted in this patch,
enhancing the scalability and conciseness of the code.
Signed-off-by: Ho-Ren (Jack) Chuang
---
drivers/dax/kmem.c | 20 ++--
include
ml/20240312061729.1997111-1-horenchu...@bytedance.com/T/#u
-v1:
*
https://lore.kernel.org/lkml/20240301082248.3456086-1-horenchu...@bytedance.com/T/#u
Ho-Ren (Jack) Chuang (2):
memory tier: dax/kmem: introduce an abstract layer for finding,
allocating, and putting memory types
memory tier:
On Wed, Mar 20, 2024 at 12:15 AM Huang, Ying wrote:
>
> "Ho-Ren (Jack) Chuang" writes:
>
> > The current implementation treats emulated memory devices, such as
> > CXL1.1 type3 memory, as normal DRAM when they are emulated as normal memory
> > (E820_TYPE_
Abstract `kmem_put_memory_types()` into `mt_put_memory_types()` to
accommodate various memory types and enhance flexibility,
similar to `mt_find_alloc_memory_type()`.
Signed-off-by: Ho-Ren (Jack) Chuang
---
drivers/dax/kmem.c | 7 +--
include/linux/memory-tiers.h | 6 ++
mm
type is created for storing all memory types that are
not initialized by device drivers and as a fallback.
Signed-off-by: Ho-Ren (Jack) Chuang
Signed-off-by: Hao Xiang
---
drivers/dax/kmem.c | 13 +
include/linux/memory-tiers.h | 7 +++
mm/memory-tiers.c| 94
()
* Use the expected way to use set_node_memory_tier instead of modifying it
*
https://lore.kernel.org/lkml/20240312061729.1997111-1-horenchu...@bytedance.com/T/#u
-v1:
*
https://lore.kernel.org/lkml/20240301082248.3456086-1-horenchu...@bytedance.com/T/#u
Ho-Ren (Jack) Chuang (2):
memory
I'm working on V3. Thanks for Ying's feedback.
cc: sthanne...@micron.com
On Thu, Mar 14, 2024 at 12:54 AM Huang, Ying wrote:
>
> "Ho-Ren (Jack) Chuang" writes:
>
> > On Tue, Mar 12, 2024 at 2:21 AM Huang, Ying wrote:
> >>
> >> &q
On Tue, Mar 12, 2024 at 2:21 AM Huang, Ying wrote:
>
> "Ho-Ren (Jack) Chuang" writes:
>
> > The current implementation treats emulated memory devices, such as
> > CXL1.1 type3 memory, as normal DRAM when they are emulated as normal memory
> > (E820_TYPE_RAM).
but also
prevents holding a large lock simultaneously.
Signed-off-by: Ho-Ren (Jack) Chuang
Signed-off-by: Hao Xiang
---
drivers/acpi/numa/hmat.c | 11 ++
drivers/dax/kmem.c | 13 +--
include/linux/acpi.h | 6
include/linux/memory-tiers.h | 8 +
mm/memory
y_tier instead of modifying it
-v1:
*
https://lore.kernel.org/linux-mm/20240301082248.3456086-1-horenchu...@bytedance.com/T/
Ho-Ren (Jack) Chuang (1):
memory tier: acpi/hmat: create CPUless memory tiers after obtaining
HMAT info
drivers/acpi/numa/hmat.c | 11 ++
drivers/dax/kmem.c
Add address-cells and size-cells information to fix warnings
for rt1019.yaml.
Signed-off-by: Jack Yu
---
Documentation/devicetree/bindings/sound/rt1019.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/rt1019.yaml
b/Documentation/devicetree
es
support OS Descriptors, so this causes count_ext_compat() to return
0 and results in the issue described in $SUBJECT.
But I think this is more of a problem of an improperly configured
ConfigFS gadget. If userspace instead removes the config from the
gadget's os_desc subdirectory that shou
> > The code is looks fine, but Jack Yu added a separate patch that makes
> > RTL1019 equivalent to RTL1015, so should this patch also handle the
> > RTL1019 case?
>
> The topology used by this machine driver is using 48k, 64fs I2S format.
> RT1019 needs to support this
> | 48k, 64fs
> >
> > Signed-off-by: Brent Lu
>
> The code is looks fine, but Jack Yu added a separate patch that makes
> RTL1019 equivalent to RTL1015, so should this patch also handle the
> RTL1019 case?
>
For rt1019 non-i2c mode (auto mode),
for it.
> This can lead to the controller accessing an unmapped memory address.
>
> Fix this by ensuring parameters to prevent EP queuing are set before
> calling the stop active transfers API.
Is it correct to say this Fixes: ae7e86108b12 ("usb: dwc3: Stop active
transfers before
Hi Vinod,
On Thu, Feb 04, 2021 at 10:39:03PM +0530, Vinod Koul wrote:
> From: Jack Pham
>
> Add device nodes for the two instances each of USB3 controllers,
> QMP SS PHYs and SNPS HS PHYs.
>
> Signed-off-by: Jack Pham
> Message-Id: <20210116013802.1609-2-ja...@codeaur
gt; +#define QSERDES_SM8350_RX_RX_MODE_10_HIGH0x188
> +#define QSERDES_SM8350_RX_RX_MODE_10_HIGH2 0x18c
> +#define QSERDES_SM8350_RX_RX_MODE_10_HIGH3 0x190
> +#define QSERDES_SM8350_RX_RX_MODE_10_HIGH4 0x194
> +#define QSERDES_SM8350_RX_DCC_CTRL1
match_desc);
>
> +int usb_gadget_check_config(struct usb_gadget *gadget, unsigned long ep_map)
You should probably add a kernel-doc for this function.
Jack
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Add compatible strings for the USB DWC3 controller on QCOM SM8150,
SM8250 and SM8350 SoCs.
Note the SM8150 & SM8250 compatibles are already being used in the
dts but was missing from the documentation.
Acked-by: Felipe Balbi
Signed-off-by: Jack Pham
---
v3: Resend of #4/4 of
h
Add the compatible strings for the USB2 PHYs found on QCOM
SM8250 & SM8350 SoCs.
Note that the SM8250 compatible is already in use in the dts and
driver implementation but was missing from the documentation.
Signed-off-by: Jack Pham
---
.../devicetree/bindings/phy/qcom,usb-snps-femto-v2.
from V4 so some of the existing
macros can be reused.
Signed-off-by: Jack Pham
---
v2: Added missing to sm8350_usb3_uniphy entry to qcom_qmp_phy_of_match_table
drivers/phy/qualcomm/phy-qcom-qmp.c | 212
drivers/phy/qualcomm/phy-qcom-qmp.h | 100 +
2
Add compatible strings for the USB DWC3 controller on QCOM SM8150,
SM8250 and SM8350 SoCs.
Note the SM8150 & SM8250 compatibles are already being used in the
dts but was missing from the documentation.
Signed-off-by: Jack Pham
---
Documentation/devicetree/bindings/usb/qcom,dwc3.yaml | 3 ++
from
the documentation.
Signed-off-by: Jack Pham
---
.../devicetree/bindings/phy/qcom,qmp-phy.yaml | 67 +++
1 file changed, 67 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml
b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml
index
: Reordered Patches 1 & 2; added missing entry to match_table
Jack Pham (4):
dt-bindings: phy: qcom,qmp: Add SM8150, SM8250 and SM8350 USB PHY
bindings
phy: qcom-qmp: Add SM8350 USB QMP PHYs
dt-bindings: phy: qcom,usb-snps-femto-v2: Add SM8250 and SM8350
bindings
dt-bindings: usb:
n
patch 1? Patch 3 and 4 are dt-bindings updates to the SNPS Femto PHY and
DWC3 QCOM docs respectively.
Will send v2, thanks.
Jack
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
On Fri, Jan 15, 2021 at 12:54:26PM +0100, Konrad Dybcio wrote:
> I might be wrong but it looks as if you forgot to add a compatible for
> the "sm8350_usb3_uniphy_cfg" configuration.
Not wrong at all! My mistake, will add it in v2.
Thanks,
Jack
--
The Qualcomm Innovation Center,
Add the compatible strings for the USB3 PHYs found on SM8150, SM8250
and SM8350 SoCs.
Note the SM8150 and SM8250 compatibles have already been in place in
the dts as well as the driver implementation but were missing from
the documentation.
Signed-off-by: Jack Pham
---
.../devicetree/bindings
Add the compatible strings for the USB2 PHYs found on QCOM
SM8250 & SM8350 SoCs.
Note that the SM8250 compatible is already in use in the dts and
driver implementation but was missing from the documentation.
Signed-off-by: Jack Pham
---
.../devicetree/bindings/phy/qcom,usb-snps-femto-v2.
This series adds support for the SM8350 USB PHY to the QMP PHY driver
as well as adds the documentation for the QMP, SNPS PHY and DWC3
controller bindings. This also adds the bindings for SM8150 and SM8250
to the same docs which had not been added previously even though they
are in use now.
Jack
Add compatible strings for the USB DWC3 controller on QCOM SM8150,
SM8250 and SM8350 SoCs.
Note the SM8150 & SM8250 compatibles are already being used in the
dts and driver implementation but was missing from the documentation.
Signed-off-by: Jack Pham
---
Documentation/devicetree/bindings
from V4 so some of the existing
macros can be reused.
Signed-off-by: Jack Pham
---
drivers/phy/qualcomm/phy-qcom-qmp.c | 209
drivers/phy/qualcomm/phy-qcom-qmp.h | 100 +
2 files changed, 309 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-q
nce the newly introduced (in patch
1/3) dwc3_gadget_vbus_draw() callback would simply be a no-op if
dwc->usb2_phy is not present.
If it does turn out to be something with your PHY driver's set_power(),
it's still puzzling since it's directed to only the usb2_phy, so I'm
curi
nch and resend?
>From the cover letter:
On Mon, Dec 21, 2020 at 06:35:27PM +0100, Jerome Brunet wrote:
> The series depends on this fix [0] by Jack Pham to apply cleanly
>
> [0]:
> https://lore.kernel.org/linux-usb/20201029175949.6052-1-ja...@codeaurora.org/
My patch hadn't be
func_unbind() as
otherwise it could lead to a dangling reference in case the function is
re-bound and userspace does not issue SS descriptors the next time.
Realistically I don't think that's possible, except maybe when fuzzing?
[1]
https://patchwork.kernel.org/project/linux-usb/patch/20201027230731.9073-1-ja...@codeaurora.org/
Jack
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
ded to them as well.
I do not work for Corsair and I intend to keep this driver maintainted
as long as I feasibly can.
Signed-off-by: Jack Doan
---
Documentation/hwmon/corsair-hxi-psu.rst | 50 +++
Documentation/hwmon/index.rst | 1 +
MAINTAINERS
/2019/october/padding-the-struct-how-a-compiler-optimization-can-disclose-stack-memory/
Hopefully this paper can serve as a helpful reference when these cases
are encountered in the kernel.
Thank you.
Jack Leadford
On 8/3/20 4:06 PM, Jason Gunthorpe wrote:
On Sun, Aug 02, 2020 at 03:45:40PM
Signed-off-by: Jack Mitchell
---
drivers/power/supply/axp20x_battery.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/drivers/power/supply/axp20x_battery.c
b/drivers/power/supply/axp20x_battery.c
index fe96f77bffa7..8ce4ebe7ccd5 100644
--- a/drivers/power
@Xiuning Would you please take a look and give some suggestion?
I don't suggest this solution for using in long term which skip call
pam-systemd.so to fix this issue, Sftp sends files and call pam-systemd.so to
create session which manage resources more reasonable, this is evolution
direction of
advance!
Best regards!
Jack Wang
status = "disabled";
Don't you also need a "usb_vbus-supply" property here under the Type-C
node pointing to the phandle of the vbus reg?
Jack
> diff --git a/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
> b/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
> i
K} bits
happen to be compatible with the struct typec's try_role() at all?
> +
> + regmap_update_bits(qcom_usb->regmap, TYPEC_VCONN_CONTROL,
> +VCONN_EN_SRC | VCONN_EN_VAL, VCONN_EN_SRC);
> + regmap_update_bits(qcom_usb->regmap, TYPEC_VCONN_CONTROL,
.
Freundliche Grüße.
Dr. Andy Jack Chin.
, DWC3_GTXFIFOSIZ(dep->number >> 1), fifo_size);
> + dwc->num_ep_resized++;
> + return 0;
> +}
> +
> static int dwc3_gadget_set_ep_config(struct dwc3_ep *dep, unsigned int
> action)
> {
> const struct usb_ss_ep_comp_descriptor *comp_desc;
> @@ -620,6 +731,10 @@ static int __dwc3_gadget_ep_enable(struct dwc3_ep *dep,
> unsigned int action)
> int ret;
>
> if (!(dep->flags & DWC3_EP_ENABLED)) {
> + ret = dwc3_gadget_resize_tx_fifos(dwc, dep);
> + if (ret)
> + return ret;
> +
> ret = dwc3_gadget_start_config(dep);
> if (ret)
> return ret;
Jack
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
ch to DMA API.
I'm curious if this was ever resolved. I just ran into this exact issue
with Android ADB which uses 16KB buffers, along with f_fs supporting
S/G since 5.0, combined with our IOMMU which performs this merging
behavior, so it resulted in a single TRB getting queued with CHN=1
etely different.
Wonder if we need to add _UFS_ to the prefix to differentiate them? Or
can this be deferred to when PCIe/USB PHY driver support for SM8150 gets
added?
I was thinking of taking a stab at USB if I get time, not sure if that's
already on your or somebody's (Bjorn?) radar.
Thanks
Jack
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
eset_quirk)
> + dwc3_gctl_core_soft_reset(dwc);
> +
In fact it is mentioned in the Synopsys databook to perform a GCTL
CoreSoftReset when changing the PrtCapDir between device & host modes.
So I think this should apply generally without a quirk. Further, it
states to do this *p
z
> or in the git tree and branch at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> linux-4.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Merged, boot and tested on my testing machine, no regression found.
Thanks,
Jack Wang
Hi Jorge, Bjorn,
On Thu, Sep 05, 2019 at 09:18:57AM +0200, Jorge Ramirez wrote:
> On 9/4/19 01:34, Bjorn Andersson wrote:
> > On Tue 03 Sep 14:45 PDT 2019, Stephen Boyd wrote:
> >
> >> Quoting Jack Pham (2019-09-03 10:39:24)
> >>> On Mon, Sep 02, 2019 at 0
wired
> >> to a USB2 phy as well, so we need to wire up detection and vbus control
> >> to both of them - but I think this will be fine, if we can only figure
> >> out a sane way of getting hold of the vbus-supply.
> >>
> >
> > Does it really matter to d
--
Attn: Are you in need of a loan? we offer all kinds of loan like
Personal
loans, Debt Consolidation Loan, Business Loan, with an interest rate of
3%
Have you been turned down by your bank? Do you have bad credit? Do you
have
unpaid bills? Are you in debt? Do you need to set up a business?
--
Attn: Are you in need of a loan? we offer all kinds of loan like
Personal
loans, Debt Consolidation Loan, Business Loan, with an interest rate of
3%
Have you been turned down by your bank? Do you have bad credit? Do you
have
unpaid bills? Are you in debt? Do you need to set up a business?
e's attr size field is 0
which is unexpected.\n"
"Was the 'perf record' command properly terminated?\n",
- data->file.path);
+ file->path);
return -EINVAL;
Regards,
Jack Wang
> d
z
> or in the git tree and branch at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> linux-4.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Merge, and regression tested on my test machines, all looks good!
Thanks,
Jack Wang
the module came from. (https://crbug.com/777204)
In a gist, I am thinking supporting this scenario would require the
module decompression to happen on the kernel side. Wondering if anyone
has looked into this before I go making a solution...
Thanks,
Jack
Paolo Bonzini 于2019年7月29日周一 上午11:10写道:
>
> On 29/07/19 10:58, Jack Wang wrote:
> > Vitaly Kuznetsov 于2019年7月25日周四 下午3:29写道:
> >>
> >> From: Paolo Bonzini
> >>
> >> [ Upstream commit 88dddc11a8d6b09201b4db9d255b3394d9bc9e57 ]
> >>
>
> Reported-by: Jan Kiszka
> Cc: Liran Alon
> Cc: sta...@vger.kernel.org
> Signed-off-by: Paolo Bonzini
Hi all,
Do we need to backport the fix also to stable 4.14? It applies
cleanly and compiles fine.
Regards,
Jack Wang
gt; git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> linux-4.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Merged and tested with my x86_64 systems, no regression found.
Regards,
Jack Wang @ 1 & 1 IONOS Cloud GmbH
gned-off-by: Elaine Zhang
>> Reviewed-by: Daniel Lezcano
>> Signed-off-by: Eduardo Valentin
>
> I can confirm that the above commit breaks my jerry, though I haven't
> dug into the details. :( Is anyone fixing? For now I'm just booting
> with the revert.
>
>
> -Doug
I can also confirm that this breaks boot on our custom board which is
very similar to the rk3288-Firefly. In my scenario the processor just
seems to "hang", no reset occurs if that helps debug matters.
Regards,
Jack.
>
> ___
> Linux-rockchip mailing list
> linux-rockc...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>
Hi Dear, my name is Jack and i am seeking for a relationship in which i will
feel loved after a series of failed relationships.
I am hoping that you would be interested and we could possibly get to know each
other more if you do not mind. I am open to answering questions from you as i
think
. Without the ability to detect a
SIGSTOP originating from tgkill, lldb does not have a way to
synchronize on a per-thread basis and falls back to SIGSTOP-ing the
entire process.
This patch allocates the siginfo as it did previously whenever the
SI_TKILL code is present.
Signed-off-by: Jack Andersen
that the flag is cleared
before it is given back to the function driver. A good place
to do that is in dwc3_gadget_del_and_unmap_request().
Fixes: c6267a51639b ("usb: dwc3: gadget: align transfers to wMaxPacketSize")
Cc: sta...@vger.kernel.org
Signed-off-by: Jack Pham
---
v2: Added F
Hi Jorge,
Sorry for the late reply as I was out during the holiday break.
On Fri, Dec 28, 2018 at 01:38:59PM +0100, Jorge Ramirez wrote:
> On 12/20/18 18:37, Jack Pham wrote:
> >Hi Rob, Jorge,
> >
> >On Thu, Dec 20, 2018 at 11:05:31AM -0600, Rob Herring wrote:
> >>
e: compatible list, contains
> "qcom,msm8996-qusb2-phy" for 14nm PHY on msm8996,
> +"qcom,msm8998-qusb2-phy" for 10nm PHY on msm8996,
should be 8998.
Thanks,
Jack
--
The Qu
1 - 100 of 470 matches
Mail list logo