Hi Peter,
On 16.10.18 07:01, Peter Chen wrote:
Most of NXP (Freescale) i.mx USB part has HSIC support, in this series,
we add support for them, it should cover all imx6 and imx7d. I have
no HSIC interface board which is supported by upstream kernel, so this
patches are only compiled ok, Frieder
Hi Peter,
please see my comments below. For reference I also pushed the changes
here: https://github.com/fschrempf/linux/commits/usb-hsic-test
On 16.10.18 07:01, Peter Chen wrote:
To support imx HSIC, there are some special requirement:
- The HSIC pad is 1.2v, it may need to supply from exter
> On 16.10.18 07:01, Peter Chen wrote:
> > Most of NXP (Freescale) i.mx USB part has HSIC support, in this
> > series, we add support for them, it should cover all imx6 and imx7d. I
> > have no HSIC interface board which is supported by upstream kernel, so
> > this patches are only compiled ok, F
Hi Peter,
On 17.10.18 09:23, Peter Chen wrote:
On 16.10.18 07:01, Peter Chen wrote:
Most of NXP (Freescale) i.mx USB part has HSIC support, in this
series, we add support for them, it should cover all imx6 and imx7d. I
have no HSIC interface board which is supported by upstream kernel, so
th
On Di, 2018-10-16 at 10:46 -0400, Alan Stern wrote:
> On Tue, 16 Oct 2018, Mayuresh Kulkarni wrote:
>
> > 1. User space decides when it is time to suspend the device and calls
> > this ioctl. The implmentation takes care to ensure, no URB is in
> > flight from this caller to this device. Then proc
On 17.10.18 11:56, Frieder Schrempf wrote:
Hi Peter,
On 17.10.18 09:23, Peter Chen wrote:
On 16.10.18 07:01, Peter Chen wrote:
Most of NXP (Freescale) i.mx USB part has HSIC support, in this
series, we add support for them, it should cover all imx6 and imx7d. I
have no HSIC interface board whi
On Wed, 17 Oct 2018, Oliver Neukum wrote:
> On Di, 2018-10-16 at 10:46 -0400, Alan Stern wrote:
> > On Tue, 16 Oct 2018, Mayuresh Kulkarni wrote:
> >
> > > 1. User space decides when it is time to suspend the device and calls
> > > this ioctl. The implmentation takes care to ensure, no URB is in
Hi,
No more leds subdirectory for this wheel, someone reports me G29 leds stays
supported correctly.
No more path: /sys/class/leds/logitechwheelpath, just my keyboard leds are
detected. Force feedback are correctly supported.
Please fix this
Cheer
Elrondo
INFO: Kernel 4.18 and older affe
On 17.10.18 13:04, Frieder Schrempf wrote:
On 17.10.18 11:56, Frieder Schrempf wrote:
[...]
- System suspend/resume
1. Enable USB wakeup
for i in $(find /sys -name wakeup | grep usb);do echo enabled >
$i;echo "echo enabled > $i";done;
2. Let the system enter suspend using below command
echo
We provide photoshop services to some of the companies from around the
world.
Some online stores use our services for retouching portraits, jewelry,
apparels, furnitures etc.
Here are the details of what we provide:
Clipping path
Deep etching
Image masking
Portrait retouching
Jewelry retouching
We provide photoshop services to some of the companies from around the
world.
Some online stores use our services for retouching portraits, jewelry,
apparels, furnitures etc.
Here are the details of what we provide:
Clipping path
Deep etching
Image masking
Portrait retouching
Jewelry retouching
uref->usage_index can be indirectly controlled by userspace, hence leading
to a potential exploitation of the Spectre variant 1 vulnerability.
This problem might show up in the cmd = HIDIOCGCOLLECTIONINDEX flow at function
hiddev_ioctl_usage(), where uref->usage_index is compared to field->maxusag
Hi Breno,
On 10/17/18 9:47 PM, Breno Leitao wrote:
> uref->usage_index can be indirectly controlled by userspace, hence leading
> to a potential exploitation of the Spectre variant 1 vulnerability.
>
> This problem might show up in the cmd = HIDIOCGCOLLECTIONINDEX flow at
> function
> hiddev_i
> > +static int ci_hdrc_imx_notify_event(struct ci_hdrc *ci, unsigned int
> > +event) {
> > + struct device *dev = ci->dev->parent;
> > + struct ci_hdrc_imx_data *data = dev_get_drvdata(dev);
> > + int ret = 0;
> > +
> > + switch (event) {
> > + case CI_HDRC_IMX_HSIC_ACTIVE_EVENT:
> >
> >>> - System suspend/resume
> >>> 1. Enable USB wakeup
> >>> for i in $(find /sys -name wakeup | grep usb);do echo enabled >
> >>> $i;echo "echo enabled > $i";done; 2. Let the system enter suspend
> >>> using below command echo mem > /sys/power/state 3. And see if there
> >>> is a wakeup block
On Wed, Oct 17, 2018 at 02:44:51PM +, elrond...@protonmail.com wrote:
>
>
> Hi,
>
> No more leds subdirectory for this wheel, someone reports me G29 leds stays
> supported correctly.
>
> No more path: /sys/class/leds/logitechwheelpath, just my keyboard leds are
> detected. Force feedback
I am Peter Wong director of operations, Hong Kong and Shanghai Banking
Corporation Limited Hong Kong. I have a very confidential business
proposition involving transfer of $18.350.000.00 that will be of great
benefit for both of us. Reply for more details as regards this
transaction
Best Regards
P
Hi,
I recently tested a board with SMSC9730 connected via USB HSIC to an
i.MX6S SOC. I used these patches on top of v4.14-rc8 for the USB HSIC
support: [1].
When I turned on autosuspend, the smsc95xx stopped in the middle of the
suspending routine and
/sys/bus/usb/devices/usb3/3-1/power/run
In dwc3_pci_quirks() function, gpiod lookup table is only registered for
baytrail SOC. But in dwc3_pci_remove(), we try to unregistered it
without any checks. This leads to NULL pointer de-reference exception in
gpiod_remove_lookup_table() when unloading the module for non baytrail
SOCs. This patch
V2 - Based on feedback, the functionality for XHCI and OHCI was
moved from Broadcom platform drivers into the standard XHCI
and OHCI platform drivers. The EHCI functionality still uses
a Broadcom EHCI driver because of the workarounds needed for
bugs in the EHCI controller.
Thi
Add support for Broadcom STB SoC's to the xhci platform driver
Signed-off-by: Al Cooper
---
drivers/usb/host/xhci-brcm.c | 17 +
drivers/usb/host/xhci-brcm.h | 16
drivers/usb/host/xhci-plat.c | 8
3 files changed, 41 insertions(+)
create mode 100644 d
Add support for Broadcom STB SoC's to the ohci platform driver.
Signed-off-by: Al Cooper
---
drivers/usb/host/ohci-platform.c | 35 +--
include/linux/usb/ohci_pdriver.h | 1 +
2 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/host/ohci-p
Add the ability to skip calling the PHY's exit routine on suspend
and the PHY's init routine on resume. This is to handle a USB PHY
that should have it's power_off function called on suspend but cannot
have it's exit function called because on exit it will disable the
PHY to the point where registe
Add a new EHCI driver for Broadcom STB SoC's. A new EHCI driver
was created instead of adding support to the existing ehci platform
driver because of the code required to workaround bugs in the EHCI
controller.
Signed-off-by: Al Cooper
---
drivers/usb/host/ehci-brcm.c | 291 +
Add the build system changes needed to get the Broadcom STB XHCI,
EHCI and OHCI functionality working. The link order for XHCI was
changed in the Makefile because of the way STB XHCI, EHCI and OHCI
controllers share a port which requires that the XHCI driver be
initialized first. Also update MAINTA
Add DT bindings document for Broadcom STB USB OHCI, EHCI and
XHCI drivers.
Signed-off-by: Al Cooper
---
.../devicetree/bindings/usb/brcm,bcm7445-ehci.txt | 22 +
.../devicetree/bindings/usb/brcm,bcm7445-ohci.txt | 22 +
.../devicetree/bindings/usb/brcm,b
Hi Bin,
On Thursday, 11 October 2018 22:31:42 EEST Bin Liu wrote:
> On Tue, Oct 09, 2018 at 10:48:57PM -0400, Paul Elder wrote:
> > This patch series adds a mechanism to allow asynchronously validating
> > the data stage of a control out request, and for stalling or suceeding
> > the request accor
Hi Bin,
On Thursday, 11 October 2018 19:10:21 EEST Bin Liu wrote:
> On Tue, Oct 09, 2018 at 10:49:01PM -0400, Paul Elder wrote:
> > A usb gadget function driver may or may not want to delay the status
> > stage of a control OUT request. An instance it might want to is to
> > asynchronously validat
hi,
On Wed, 2018-10-17 at 18:29 -0400, Al Cooper wrote:
> Add the ability to skip calling the PHY's exit routine on suspend
> and the PHY's init routine on resume. This is to handle a USB PHY
> that should have it's power_off function called on suspend but cannot
> have it's exit function called b
29 matches
Mail list logo
