Re: [PATCH 1/9] net: mediatek: update the IRQ part of the binding document

Every patch series must begin with a postings labelled "[PATCH 0/9] ..." which explains what the series is doing, how it is implementing that, and why it is implemented that way.

Re: [PATCH 1/9] net: mediatek: update the IRQ part of the binding document

Every patch series must begin with a postings labelled "[PATCH 0/9] ..." which explains what the series is doing, how it is implementing that, and why it is implemented that way.

[RESEND/PATCH V7 2/2] regulator: mt6323: Add support for MT6323 regulator

From: Chen Zhong The MT6323 is a regulator found on boards based on MediaTek MT7623 and probably other SoCs. It is a so called pmic and connects as a slave to SoC using SPI, wrapped inside the pmic-wrapper. Signed-off-by: Chen Zhong

[RESEND/PATCH V7 2/2] regulator: mt6323: Add support for MT6323 regulator

From: Chen Zhong The MT6323 is a regulator found on boards based on MediaTek MT7623 and probably other SoCs. It is a so called pmic and connects as a slave to SoC using SPI, wrapped inside the pmic-wrapper. Signed-off-by: Chen Zhong Signed-off-by: John Crispin --- Series was dropped in the

[RESEND/PATCH V7 1/2] regulator: Add document for MT6323 regulator

Signed-off-by: John Crispin Cc: devicet...@vger.kernel.org --- Series was dropped in the 4.6-rc1 merge window to avoid a merge order conflict with the corresponding MFD driver. Changes in V7 * remove another compatible string * small wording changes Changes in V6 * remove

[RESEND/PATCH V7 1/2] regulator: Add document for MT6323 regulator

Signed-off-by: John Crispin Cc: devicet...@vger.kernel.org --- Series was dropped in the 4.6-rc1 merge window to avoid a merge order conflict with the corresponding MFD driver. Changes in V7 * remove another compatible string * small wording changes Changes in V6 * remove the compatible string

Re: [PATCH] ARM: dts: k2*: Rename the k2* files to keystone-k2* files

On Thu, Apr 7, 2016 at 1:39 PM, santosh.shilim...@oracle.com wrote: > On 4/7/16 10:01 AM, Nishanth Menon wrote: >> >> Hi Santosh, >> >> On Wed, Mar 16, 2016 at 10:43 AM, santosh shilimkar >> wrote: >>> >>> On 3/16/2016 7:39 AM, Nishanth

Re: [PATCH] ARM: dts: k2*: Rename the k2* files to keystone-k2* files

On Thu, Apr 7, 2016 at 1:39 PM, santosh.shilim...@oracle.com wrote: > On 4/7/16 10:01 AM, Nishanth Menon wrote: >> >> Hi Santosh, >> >> On Wed, Mar 16, 2016 at 10:43 AM, santosh shilimkar >> wrote: >>> >>> On 3/16/2016 7:39 AM, Nishanth Menon wrote: As reported in [1], rename the

Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number of running thread

- On Apr 7, 2016, at 12:52 PM, Linus Torvalds torva...@linux-foundation.org wrote: > On Thu, Apr 7, 2016 at 9:39 AM, Linus Torvalds > wrote: >> >> Because if not, then this discussion is done for. Stop with the >> f*cking idiotic "let's look at some kernel

Re: [RFT PATCH 0/4] usb: dwc2: Fix core reset and force mode delay problems

On 3/31/2016 2:44 PM, Michael Niewoehner wrote: > Hi John, > > Am 29.03.2016 um 04:36 schrieb John Youn : > >> Hi, >> >> The following patch series addresses the core reset and force mode >> delay problems we have been seeing on dwc2 for some platforms. >> >> I think I

Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number of running thread

- On Apr 7, 2016, at 12:52 PM, Linus Torvalds torva...@linux-foundation.org wrote: > On Thu, Apr 7, 2016 at 9:39 AM, Linus Torvalds > wrote: >> >> Because if not, then this discussion is done for. Stop with the >> f*cking idiotic "let's look at some kernel size and user-space size >> and

Re: [RFT PATCH 0/4] usb: dwc2: Fix core reset and force mode delay problems

On 3/31/2016 2:44 PM, Michael Niewoehner wrote: > Hi John, > > Am 29.03.2016 um 04:36 schrieb John Youn : > >> Hi, >> >> The following patch series addresses the core reset and force mode >> delay problems we have been seeing on dwc2 for some platforms. >> >> I think I have identified the source

Re: [PATCH] ARM: dts: k2*: Rename the k2* files to keystone-k2* files

On 4/7/16 10:01 AM, Nishanth Menon wrote: Hi Santosh, On Wed, Mar 16, 2016 at 10:43 AM, santosh shilimkar wrote: On 3/16/2016 7:39 AM, Nishanth Menon wrote: As reported in [1], rename the k2* dts files to keystone-* files this will force consistency throughout.

Re: [PATCH] ARM: dts: k2*: Rename the k2* files to keystone-k2* files

On 4/7/16 10:01 AM, Nishanth Menon wrote: Hi Santosh, On Wed, Mar 16, 2016 at 10:43 AM, santosh shilimkar wrote: On 3/16/2016 7:39 AM, Nishanth Menon wrote: As reported in [1], rename the k2* dts files to keystone-* files this will force consistency throughout. Script for the same (and

[PATCH v2] mvsas: Generalize Marvell 9485 in pci_device_id

For generic subvendor has sense to use generic subdevice. If subdevice ID not equal to 0x9480/0x9485 mvsas will be not activated. Tested on ASUS P9A-I/C2550/SAS/4L which uses vendor-specific 1043:8635. Signed-off-by: Leonid Moiseichuk ---

[PATCH v2] mvsas: Generalize Marvell 9485 in pci_device_id

For generic subvendor has sense to use generic subdevice. If subdevice ID not equal to 0x9480/0x9485 mvsas will be not activated. Tested on ASUS P9A-I/C2550/SAS/4L which uses vendor-specific 1043:8635. Signed-off-by: Leonid Moiseichuk --- drivers/scsi/mvsas/mv_init.c | 19 +--

Re: [PATCH 2/3] orangefs: strncpy -> strlcpy

On Mon, Apr 4, 2016 at 11:26 PM, Martin Brandenburg wrote: > From: Martin Brandenburg > > Almost everywhere we use strncpy we should use strlcpy. This affects > path names (d_name mostly), symlink targets, and server names. > > Leave debugfs code as is

Re: [PATCH 2/3] orangefs: strncpy -> strlcpy

On Mon, Apr 4, 2016 at 11:26 PM, Martin Brandenburg wrote: > From: Martin Brandenburg > > Almost everywhere we use strncpy we should use strlcpy. This affects > path names (d_name mostly), symlink targets, and server names. > > Leave debugfs code as is for now, though it could use a review as

[GIT PULL] ext4 bug fixes for 4.6

The following changes since commit 243d50678583100855862bc084b8b307eea67f68: Merge branch 'overlayfs-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs (2016-03-22 13:11:15 -0700) are available in the git repository at:

Re: [PATCH v2] mvsas: Generalize Marvell 9485 in pci_device_id

On Thu, Apr 7, 2016 at 8:06 PM, Leonid Moiseichuk wrote: > For generic subvendor has sense to use generic subdevice. > If subdevice ID not equal to 0x9480/0x9485 mvsas will be not activated. > > Tested on ASUS P9A-I/C2550/SAS/4L which uses vendor-specific 1043:8635.

[GIT PULL] ext4 bug fixes for 4.6

The following changes since commit 243d50678583100855862bc084b8b307eea67f68: Merge branch 'overlayfs-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs (2016-03-22 13:11:15 -0700) are available in the git repository at:

Re: [PATCH v2] mvsas: Generalize Marvell 9485 in pci_device_id

On Thu, Apr 7, 2016 at 8:06 PM, Leonid Moiseichuk wrote: > For generic subvendor has sense to use generic subdevice. > If subdevice ID not equal to 0x9480/0x9485 mvsas will be not activated. > > Tested on ASUS P9A-I/C2550/SAS/4L which uses vendor-specific 1043:8635. Minors below. FWIW:

Re: [RFC PATCH v1.9 00/14] livepatch: hybrid consistency model

On Thu, 7 Apr 2016, Josh Poimboeuf wrote: > > I admittedly forgot what the "ftrace handler switching idea" is, and am > > not sure where exactly to look for it (could you please point it to me so > > that I can refresh my memory) > > Here's where I originally described it [1]: Thanks! > | 2)

Re: [RFC PATCH v1.9 00/14] livepatch: hybrid consistency model

On Thu, 7 Apr 2016, Josh Poimboeuf wrote: > > I admittedly forgot what the "ftrace handler switching idea" is, and am > > not sure where exactly to look for it (could you please point it to me so > > that I can refresh my memory) > > Here's where I originally described it [1]: Thanks! > | 2)

Re: How to get creatior PID information for the local tcp connection

On Thu, 2016-04-07 at 11:26 -0700, Eric Dumazet wrote: > On Thu, 2016-04-07 at 23:01 +0530, Vishnu Pratap Singh wrote: > > Hi, > > > > > > Issue - How to get PID information for the local tcp connection > > > > > > > > i want to get the creator PID for each socket in user space for local > >

Re: How to get creatior PID information for the local tcp connection

On Thu, 2016-04-07 at 11:26 -0700, Eric Dumazet wrote: > On Thu, 2016-04-07 at 23:01 +0530, Vishnu Pratap Singh wrote: > > Hi, > > > > > > Issue - How to get PID information for the local tcp connection > > > > > > > > i want to get the creator PID for each socket in user space for local > >

Re: [PATCH v6 2/5] vfio: allow the user to register reserved iova range for MSI mapping

On Thu, 7 Apr 2016 15:43:29 +0200 Eric Auger wrote: > Hi Alex, > On 04/07/2016 12:07 AM, Alex Williamson wrote: > > On Mon, 4 Apr 2016 08:30:08 + > > Eric Auger wrote: > > > >> The user is allowed to [un]register a reserved IOVA range by

Re: [PATCH v6 2/5] vfio: allow the user to register reserved iova range for MSI mapping

On Thu, 7 Apr 2016 15:43:29 +0200 Eric Auger wrote: > Hi Alex, > On 04/07/2016 12:07 AM, Alex Williamson wrote: > > On Mon, 4 Apr 2016 08:30:08 + > > Eric Auger wrote: > > > >> The user is allowed to [un]register a reserved IOVA range by using the > >> DMA MAP API and setting the new

Re: How to get creatior PID information for the local tcp connection

On Thu, 2016-04-07 at 23:01 +0530, Vishnu Pratap Singh wrote: > Hi, > > > Issue - How to get PID information for the local tcp connection > > > > i want to get the creator PID for each socket in user space for local > tcp connection, i see in kernel there is support for returing PID with >

Re: How to get creatior PID information for the local tcp connection

On Thu, 2016-04-07 at 23:01 +0530, Vishnu Pratap Singh wrote: > Hi, > > > Issue - How to get PID information for the local tcp connection > > > > i want to get the creator PID for each socket in user space for local > tcp connection, i see in kernel there is support for returing PID with >

[PATCH] net-next: mediatek: add support for IRQ grouping

The ethernet core has 3 IRQs. Using the IRQ grouping registers we are able to separate TX and RX IRQs, which allows us to service them on separate cores. This patch splits the IRQ handler into 2 separate functions, one for TX and another for RX. The TX housekeeping is split out of the NAPI

[PATCH] net-next: mediatek: add support for IRQ grouping

The ethernet core has 3 IRQs. Using the IRQ grouping registers we are able to separate TX and RX IRQs, which allows us to service them on separate cores. This patch splits the IRQ handler into 2 separate functions, one for TX and another for RX. The TX housekeeping is split out of the NAPI

Re: Problems with commit a770d946371e ("gpio: pxa: add pin control gpio direction and request")

Guenter Roeck writes: >> But no more poor excuses, would you try the patch at the end of this mail, >> while >> I'm doing the same on my Jenkins, on both device-tree and legacy >> platform-data >> builds, to see if we can fix this ? >> >> Cheers. > Any updates ? I still

Re: livepatch: robustify klp_register_patch() API error checking

+++ Jiri Kosina [07/04/16 18:06 +0200]: From: Jiri Kosina Commit 425595a7fc20 ("livepatch: reuse module loader code to write relocations") adds a possibility of dereferncing pointers supplied by the consumer of the livepatch API before sanity (NULL) checking them (patch and

Re: Problems with commit a770d946371e ("gpio: pxa: add pin control gpio direction and request")

Guenter Roeck writes: >> But no more poor excuses, would you try the patch at the end of this mail, >> while >> I'm doing the same on my Jenkins, on both device-tree and legacy >> platform-data >> builds, to see if we can fix this ? >> >> Cheers. > Any updates ? I still see the problem in

Re: livepatch: robustify klp_register_patch() API error checking

+++ Jiri Kosina [07/04/16 18:06 +0200]: From: Jiri Kosina Commit 425595a7fc20 ("livepatch: reuse module loader code to write relocations") adds a possibility of dereferncing pointers supplied by the consumer of the livepatch API before sanity (NULL) checking them (patch and patch->mod).

Re: [PATCH] kvm: x86: do not leak guest xcr0 into host interrupt handlers

On Thu, Apr 7, 2016 at 2:08 AM, Paolo Bonzini wrote: > > > On 05/04/2016 17:56, David Matlack wrote: >> On Tue, Apr 5, 2016 at 4:28 AM, Paolo Bonzini wrote: >>> >> ... >>> >>> While running my acceptance tests, in one case I got one CPU whose xcr0 >>>

Re: [PATCH] kvm: x86: do not leak guest xcr0 into host interrupt handlers

On Thu, Apr 7, 2016 at 2:08 AM, Paolo Bonzini wrote: > > > On 05/04/2016 17:56, David Matlack wrote: >> On Tue, Apr 5, 2016 at 4:28 AM, Paolo Bonzini wrote: >>> >> ... >>> >>> While running my acceptance tests, in one case I got one CPU whose xcr0 >>> had leaked into the host. This showed up as

Re: Regulator: drivers that need to know their supply

Thanks for your reply. On 07/04/16 19:02, Mark Brown wrote: On Thu, Apr 07, 2016 at 03:25:09PM +0200, Martin Fuzzey wrote: To implement the .enable_time() method I need the voltage (which is the supply's voltage). No, this is not sensible. You should be telling the framework about the slew

Re: Regulator: drivers that need to know their supply

Thanks for your reply. On 07/04/16 19:02, Mark Brown wrote: On Thu, Apr 07, 2016 at 03:25:09PM +0200, Martin Fuzzey wrote: To implement the .enable_time() method I need the voltage (which is the supply's voltage). No, this is not sensible. You should be telling the framework about the slew

Re: [PATCH 1/2] regulator: s2mps11: Use module_platform_driver() instead subsys initcall

Hello Krzysztof, On 04/07/2016 08:30 AM, Krzysztof Kozlowski wrote: > On Wed, Apr 06, 2016 at 09:49:46AM -0400, Javier Martinez Canillas wrote: >> The driver's init and exit function don't do anything besides registering >> and unregistering the platform driver, so the module_platform_driver() >>

Re: [PATCH 1/2] regulator: s2mps11: Use module_platform_driver() instead subsys initcall

Hello Krzysztof, On 04/07/2016 08:30 AM, Krzysztof Kozlowski wrote: > On Wed, Apr 06, 2016 at 09:49:46AM -0400, Javier Martinez Canillas wrote: >> The driver's init and exit function don't do anything besides registering >> and unregistering the platform driver, so the module_platform_driver() >>

Re: [PATCH] staging: rtl8192u: remove blank lines after braces (opening)

On Thu, 2016-04-07 at 21:06 +0300, Andy Shevchenko wrote: > On Thu, Apr 7, 2016 at 9:04 PM, Joe Perches wrote: > > On Thu, 2016-04-07 at 20:59 +0300, Andy Shevchenko wrote: > > > On Tue, Apr 5, 2016 at 7:07 PM, Nicholas Sim wrote: > > > > > > > > Remove unneeded blank lines

Re: [PATCH] staging: rtl8192u: remove blank lines after braces (opening)

On Thu, 2016-04-07 at 21:06 +0300, Andy Shevchenko wrote: > On Thu, Apr 7, 2016 at 9:04 PM, Joe Perches wrote: > > On Thu, 2016-04-07 at 20:59 +0300, Andy Shevchenko wrote: > > > On Tue, Apr 5, 2016 at 7:07 PM, Nicholas Sim wrote: > > > > > > > > Remove unneeded blank lines appearing after

Re: [PATCH 1/2] qcom: ipq4019: Add regulator support to DK04 device tree

On Thu, Apr 07, 2016 at 12:57:36PM -0500, Rob Herring wrote: > On Mon, Apr 04, 2016 at 02:08:10PM -0700, Sreedhar Sambangi wrote: > > This adds the regulator nodes to DK04 device tree to support > > > > Change-Id: I9c1df0e720a330bf6db1889fd2247f6a70ea6faa > > Signed-off-by: Sreedhar Sambangi

Re: [PATCH 1/2] qcom: ipq4019: Add regulator support to DK04 device tree

On Thu, Apr 07, 2016 at 12:57:36PM -0500, Rob Herring wrote: > On Mon, Apr 04, 2016 at 02:08:10PM -0700, Sreedhar Sambangi wrote: > > This adds the regulator nodes to DK04 device tree to support > > > > Change-Id: I9c1df0e720a330bf6db1889fd2247f6a70ea6faa > > Signed-off-by: Sreedhar Sambangi

Re: [PATCH] staging: rtl8192u: remove blank lines after braces (opening)

On Thu, Apr 7, 2016 at 9:04 PM, Joe Perches wrote: > On Thu, 2016-04-07 at 20:59 +0300, Andy Shevchenko wrote: >> On Tue, Apr 5, 2016 at 7:07 PM, Nicholas Sim wrote: >> > >> > Remove unneeded blank lines appearing after opening braces as suggested >> >

Re: [PATCH] staging: rtl8192u: remove blank lines after braces (opening)

On Thu, Apr 7, 2016 at 9:04 PM, Joe Perches wrote: > On Thu, 2016-04-07 at 20:59 +0300, Andy Shevchenko wrote: >> On Tue, Apr 5, 2016 at 7:07 PM, Nicholas Sim wrote: >> > >> > Remove unneeded blank lines appearing after opening braces as suggested >> > by checkpatch.pl >> > >> You have to

Re: [PATCH] i2c: designware-platdrv: get fast/std speed scl high/low count from DT

On Wed, Apr 6, 2016 at 10:28 AM, Jisheng Zhang wrote: > Sometimes, it's convenient to define the scl's high/low count directly, > e.g HW people would do some measurement then directly give out the > optimum counts. Previously, we solved the sda falling time and scl > falling

Re: [PATCH] i2c: designware-platdrv: get fast/std speed scl high/low count from DT

On Wed, Apr 6, 2016 at 10:28 AM, Jisheng Zhang wrote: > Sometimes, it's convenient to define the scl's high/low count directly, > e.g HW people would do some measurement then directly give out the > optimum counts. Previously, we solved the sda falling time and scl > falling time by

Applied "ASoC: dwc: Use fifo depth to program FCR" to the asoc tree

The patch ASoC: dwc: Use fifo depth to program FCR has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus

Re: [PATCH] staging: rtl8192u: remove blank lines after braces (opening)

On Thu, 2016-04-07 at 20:59 +0300, Andy Shevchenko wrote: > On Tue, Apr 5, 2016 at 7:07 PM, Nicholas Sim wrote: > > > > Remove unneeded blank lines appearing after opening braces as suggested > > by checkpatch.pl > > > You have to combine this with the rest so called

Re: [RFC PATCH 0/4] Add ACPI support for pinctrl configuration

On Thu, Apr 7, 2016 at 4:17 PM, Octavian Purdila wrote: > On Wed, Apr 6, 2016 at 1:49 PM, Graeme Gregory wrote: >> Why has there been no attempt in ASWG to make these sort of features a >> 1st class citizen of ACPI so they can interact correctly

Re: [RFC PATCH v1.9 00/14] livepatch: hybrid consistency model

On Thu, Apr 07, 2016 at 05:47:00PM +0200, Jiri Kosina wrote: > On Thu, 7 Apr 2016, Josh Poimboeuf wrote: > > > > > - try ftrace handler switching idea from v1 cover letter > [ ... ] > > > We probably should not check the stack in atomic context > > > > Can you elaborate why not? > > I

Re: [PATCH v2 3/5] dmaengine: qcom: bam_dma: add controlled remotely dt property

On Wed, Apr 06, 2016 at 01:56:20AM +0300, Stanimir Varbanov wrote: > Some of the peripherals has bam which is controlled by remote > processor, thus the bam dma driver must avoid register writes > which initialise bam hw block. Those registers are protected > from xPU block and any writes to them

Applied "ASoC: dwc: Use fifo depth to program FCR" to the asoc tree

The patch ASoC: dwc: Use fifo depth to program FCR has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus

Re: [PATCH] staging: rtl8192u: remove blank lines after braces (opening)

On Thu, 2016-04-07 at 20:59 +0300, Andy Shevchenko wrote: > On Tue, Apr 5, 2016 at 7:07 PM, Nicholas Sim wrote: > > > > Remove unneeded blank lines appearing after opening braces as suggested > > by checkpatch.pl > > > You have to combine this with the rest so called 'indentation' fixes, > e.g.

Re: [RFC PATCH 0/4] Add ACPI support for pinctrl configuration

On Thu, Apr 7, 2016 at 4:17 PM, Octavian Purdila wrote: > On Wed, Apr 6, 2016 at 1:49 PM, Graeme Gregory wrote: >> Why has there been no attempt in ASWG to make these sort of features a >> 1st class citizen of ACPI so they can interact correctly with the other >> features? > > IMO having an

Re: [RFC PATCH v1.9 00/14] livepatch: hybrid consistency model

On Thu, Apr 07, 2016 at 05:47:00PM +0200, Jiri Kosina wrote: > On Thu, 7 Apr 2016, Josh Poimboeuf wrote: > > > > > - try ftrace handler switching idea from v1 cover letter > [ ... ] > > > We probably should not check the stack in atomic context > > > > Can you elaborate why not? > > I

Re: [PATCH v2 3/5] dmaengine: qcom: bam_dma: add controlled remotely dt property

On Wed, Apr 06, 2016 at 01:56:20AM +0300, Stanimir Varbanov wrote: > Some of the peripherals has bam which is controlled by remote > processor, thus the bam dma driver must avoid register writes > which initialise bam hw block. Those registers are protected > from xPU block and any writes to them

Re: [PATCH RFC 1/5] net: phy: sun8i-h3-ephy: Add bindings for Allwinner H3 Ethernet PHY

On Tue, Apr 05, 2016 at 12:22:30AM +0800, Chen-Yu Tsai wrote: > The Allwinner H3 SoC incorporates an Ethernet PHY. This is enabled and > configured through a memory mapped hardware register. > > This same register also configures the MAC interface mode and TX clock > source. Also covered by the

Re: [PATCH] i2c: designware-platdrv: get fast/std speed scl high/low count from DT

On Wed, Apr 06, 2016 at 03:28:00PM +0800, Jisheng Zhang wrote: > Sometimes, it's convenient to define the scl's high/low count directly, > e.g HW people would do some measurement then directly give out the > optimum counts. Previously, we solved the sda falling time and scl > falling time by

[PATCH 3/9] net: mediatek: mtk_cal_txd_req() returns bad value

The code used to also support the PDMA engine, which had 2 packet pointers per descriptor. Because of this we had to divide the result by 2 and round it up. This is no longer needed as the code only supports QDMA. Signed-off-by: John Crispin ---

Re: [PATCH RFC 1/5] net: phy: sun8i-h3-ephy: Add bindings for Allwinner H3 Ethernet PHY

On Tue, Apr 05, 2016 at 12:22:30AM +0800, Chen-Yu Tsai wrote: > The Allwinner H3 SoC incorporates an Ethernet PHY. This is enabled and > configured through a memory mapped hardware register. > > This same register also configures the MAC interface mode and TX clock > source. Also covered by the

Re: [PATCH] i2c: designware-platdrv: get fast/std speed scl high/low count from DT

On Wed, Apr 06, 2016 at 03:28:00PM +0800, Jisheng Zhang wrote: > Sometimes, it's convenient to define the scl's high/low count directly, > e.g HW people would do some measurement then directly give out the > optimum counts. Previously, we solved the sda falling time and scl > falling time by

[PATCH 3/9] net: mediatek: mtk_cal_txd_req() returns bad value

The code used to also support the PDMA engine, which had 2 packet pointers per descriptor. Because of this we had to divide the result by 2 and round it up. This is no longer needed as the code only supports QDMA. Signed-off-by: John Crispin --- drivers/net/ethernet/mediatek/mtk_eth_soc.c |

Re: [PATCH] livepatch: robustify klp_register_patch() API error checking

On Thu, Apr 07, 2016 at 06:06:25PM +0200, Jiri Kosina wrote: > From: Jiri Kosina > > Commit 425595a7fc20 ("livepatch: reuse module loader code to write > relocations") adds a possibility of dereferncing pointers supplied by the > consumer of the livepatch API before sanity

Re: [PATCH] livepatch: robustify klp_register_patch() API error checking

On Thu, Apr 07, 2016 at 06:06:25PM +0200, Jiri Kosina wrote: > From: Jiri Kosina > > Commit 425595a7fc20 ("livepatch: reuse module loader code to write > relocations") adds a possibility of dereferncing pointers supplied by the > consumer of the livepatch API before sanity (NULL) checking them

[PATCH 1/9] net: mediatek: update the IRQ part of the binding document

The current binding document only describes a single interrupt. Update the document by adding the 2 other interrupts. The driver currently only uses a single interrupt. The HW is however able to using IRQ grouping to split TX and RX onto separate GIC irqs. Signed-off-by: John Crispin

[PATCH 1/9] net: mediatek: update the IRQ part of the binding document

The current binding document only describes a single interrupt. Update the document by adding the 2 other interrupts. The driver currently only uses a single interrupt. The HW is however able to using IRQ grouping to split TX and RX onto separate GIC irqs. Signed-off-by: John Crispin Cc:

Re: [PATCH] ASoC: rockchip: i2s: configure the sdio pins' iomux mode

On Wed, Apr 06, 2016 at 04:38:22PM +0800, Sugar Zhang wrote: > There are 3 i2s sdio pins, which iomux mode is as follows: s/i2s sdio/I2S\/SDIO muxed/ > > - sdi3_sdo1 > - sdi2_sdo2 > - sdi1_sdo3 > > we need to configure these pins' iomux mode via the GRF register > when use multi channel

[PATCH 9/9] net: mediatek: do not set the QID field in the TX DMA descriptors

The QID field gets set to the mac id. This made the DMA linked list queue the traffic of each MAC on a different internal queue. However during long term testing we found that this will cause traffic stalls as the multi queue setup requires a more complete initialisation which is not part of the

[PATCH 6/9] net: mediatek: fix mtk_pending_work

The driver supports 2 MACs. Both run on the same DMA ring. If we hit a TX timeout we need to stop both netdevs before restarting them again. If we don't do this, mtk_stop() wont shutdown DMA and the consecutive call to mtk_open() wont restart DMA and enable IRQs. Signed-off-by: John Crispin

[PATCH 5/9] net: mediatek: fix stop and wakeup of queue

The driver supports 2 MACs. Both run on the same DMA ring. If we go above/below the TX rings threshold value, we always need to wake/stop the queue of both devices. Not doing to can cause TX stalls and packet drops on one of the devices. Signed-off-by: John Crispin ---

Re: [PATCH] ASoC: rockchip: i2s: configure the sdio pins' iomux mode

On Wed, Apr 06, 2016 at 04:38:22PM +0800, Sugar Zhang wrote: > There are 3 i2s sdio pins, which iomux mode is as follows: s/i2s sdio/I2S\/SDIO muxed/ > > - sdi3_sdo1 > - sdi2_sdo2 > - sdi1_sdo3 > > we need to configure these pins' iomux mode via the GRF register > when use multi channel

[PATCH 9/9] net: mediatek: do not set the QID field in the TX DMA descriptors

The QID field gets set to the mac id. This made the DMA linked list queue the traffic of each MAC on a different internal queue. However during long term testing we found that this will cause traffic stalls as the multi queue setup requires a more complete initialisation which is not part of the

[PATCH 6/9] net: mediatek: fix mtk_pending_work

The driver supports 2 MACs. Both run on the same DMA ring. If we hit a TX timeout we need to stop both netdevs before restarting them again. If we don't do this, mtk_stop() wont shutdown DMA and the consecutive call to mtk_open() wont restart DMA and enable IRQs. Signed-off-by: John Crispin ---

[PATCH 5/9] net: mediatek: fix stop and wakeup of queue

The driver supports 2 MACs. Both run on the same DMA ring. If we go above/below the TX rings threshold value, we always need to wake/stop the queue of both devices. Not doing to can cause TX stalls and packet drops on one of the devices. Signed-off-by: John Crispin ---

Re: [PATCH] staging: rtl8192u: remove blank lines after braces (opening)

On Tue, Apr 5, 2016 at 7:07 PM, Nicholas Sim wrote: > Remove unneeded blank lines appearing after opening braces as suggested > by checkpatch.pl > You have to combine this with the rest so called 'indentation' fixes, e.g. +- empty lines, tabs vs. spaces, etc. P.S. By

[PATCH 8/9] net: mediatek: move the pending_work struct to the device generic struct

The worker always touches both netdevs. It is ethernet core and not MAC specific. We only need one worker, which belongs into the ethernets core struct. Signed-off-by: John Crispin --- drivers/net/ethernet/mediatek/mtk_eth_soc.c | 10 --

Re: [PATCH 1/2] thermal: generic-adc: Add DT binding for ADC based thermal sensor driver

On Wed, Apr 06, 2016 at 03:33:05PM +0530, Laxman Dewangan wrote: > Sometimes, thermal sensors like NCT thermistors are connected to > the ADC channel. The temperature is read by reading the voltage > across the sensor resistance via ADC and referring the lookup > table for ADC value to

[PATCH 4/9] net: mediatek: remove superfluous reset call

HW reset is triggered in the mtk_hw_init() function. There is no need to also reset the core during probe. Signed-off-by: John Crispin --- drivers/net/ethernet/mediatek/mtk_eth_soc.c |4 1 file changed, 4 deletions(-) diff --git

Re: [PATCH] staging: rtl8192u: remove blank lines after braces (opening)

On Tue, Apr 5, 2016 at 7:07 PM, Nicholas Sim wrote: > Remove unneeded blank lines appearing after opening braces as suggested > by checkpatch.pl > You have to combine this with the rest so called 'indentation' fixes, e.g. +- empty lines, tabs vs. spaces, etc. P.S. By the way. are they first

[PATCH 8/9] net: mediatek: move the pending_work struct to the device generic struct

The worker always touches both netdevs. It is ethernet core and not MAC specific. We only need one worker, which belongs into the ethernets core struct. Signed-off-by: John Crispin --- drivers/net/ethernet/mediatek/mtk_eth_soc.c | 10 -- drivers/net/ethernet/mediatek/mtk_eth_soc.h |

Re: [PATCH 1/2] thermal: generic-adc: Add DT binding for ADC based thermal sensor driver

On Wed, Apr 06, 2016 at 03:33:05PM +0530, Laxman Dewangan wrote: > Sometimes, thermal sensors like NCT thermistors are connected to > the ADC channel. The temperature is read by reading the voltage > across the sensor resistance via ADC and referring the lookup > table for ADC value to

[PATCH 4/9] net: mediatek: remove superfluous reset call

HW reset is triggered in the mtk_hw_init() function. There is no need to also reset the core during probe. Signed-off-by: John Crispin --- drivers/net/ethernet/mediatek/mtk_eth_soc.c |4 1 file changed, 4 deletions(-) diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c

[PATCH 2/9] net: mediatek: watchdog_timeo was not set

The original commit failed to set watchdog_timeo. This patch sets watchdog_timeo to HZ. Signed-off-by: John Crispin --- drivers/net/ethernet/mediatek/mtk_eth_soc.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c

[PATCH 2/9] net: mediatek: watchdog_timeo was not set

The original commit failed to set watchdog_timeo. This patch sets watchdog_timeo to HZ. Signed-off-by: John Crispin --- drivers/net/ethernet/mediatek/mtk_eth_soc.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c

Re: [PATCH v3 4/9] drm/fsl-dcu: add extra clock for pixel clock

On Mon, Apr 04, 2016 at 10:28:36PM -0700, Stefan Agner wrote: > The Vybrid DCU variant has two independent clock inputs, one > for the registers (IPG bus clock) and one for the pixel clock. > Support this distinction in the DCU DRM driver while staying > backward compatible for old device trees. >

Re: [PATCH v1] regulator: twl: Provide of_map_mode for twl4030

On Tue, Apr 05, 2016 at 08:59:34AM +0300, Ivaylo Dimitrov wrote: > of_map_mode is needed so to be possible to set initial regulators mode from > the board DTS. Otherwise, for DT boot, regulators are left in their default > state after reset/reboot. Document device specific modes as well. > >

[PATCH 7/9] net: mediatek: fix TX locking

Inside the TX path there is a lock inside the tx_map function. This is however too late. The patch moves the lock to the start of the xmit function right before the free count check of the DMA ring happens. If we do not do this, the code becomes racy leading to TX stalls and dropped packets. This

Re: [PATCH v2 2/2] devicetree: document NXP LPC1850 PINT irq controller binding

On Sat, Apr 02, 2016 at 06:35:24PM +0200, Joachim Eastwood wrote: > Add binding documentation for NXP LPC1850 GPIO Pin Interrupt (PINT) > controller. > > Signed-off-by: Joachim Eastwood > --- > .../interrupt-controller/nxp,lpc1850-gpio-pint.txt | 26 > ++

Re: [PATCH v3 4/9] drm/fsl-dcu: add extra clock for pixel clock

On Mon, Apr 04, 2016 at 10:28:36PM -0700, Stefan Agner wrote: > The Vybrid DCU variant has two independent clock inputs, one > for the registers (IPG bus clock) and one for the pixel clock. > Support this distinction in the DCU DRM driver while staying > backward compatible for old device trees. >

Re: [PATCH v1] regulator: twl: Provide of_map_mode for twl4030

On Tue, Apr 05, 2016 at 08:59:34AM +0300, Ivaylo Dimitrov wrote: > of_map_mode is needed so to be possible to set initial regulators mode from > the board DTS. Otherwise, for DT boot, regulators are left in their default > state after reset/reboot. Document device specific modes as well. > >

[PATCH 7/9] net: mediatek: fix TX locking

Inside the TX path there is a lock inside the tx_map function. This is however too late. The patch moves the lock to the start of the xmit function right before the free count check of the DMA ring happens. If we do not do this, the code becomes racy leading to TX stalls and dropped packets. This

Re: [PATCH v2 2/2] devicetree: document NXP LPC1850 PINT irq controller binding

On Sat, Apr 02, 2016 at 06:35:24PM +0200, Joachim Eastwood wrote: > Add binding documentation for NXP LPC1850 GPIO Pin Interrupt (PINT) > controller. > > Signed-off-by: Joachim Eastwood > --- > .../interrupt-controller/nxp,lpc1850-gpio-pint.txt | 26 > ++ > 1 file changed,

Re: [PATCH v12 8/9] add TC G210 platform driver

On Mon, Apr 04, 2016 at 11:48:23AM +0100, Joao Pinto wrote: > > Hi Rob, > > On 4/4/2016 6:15 AM, Rob Herring wrote: > > On Thu, Mar 31, 2016 at 07:57:21PM +0100, Joao Pinto wrote: > >> This patch adds a glue platform driver for the Synopsys G210 Test Chip. > >> > >> Signed-off-by: Joao Pinto

Re: [PATCH 1/2] qcom: ipq4019: Add regulator support to DK04 device tree

On Mon, Apr 04, 2016 at 02:08:10PM -0700, Sreedhar Sambangi wrote: > This adds the regulator nodes to DK04 device tree to support > > Change-Id: I9c1df0e720a330bf6db1889fd2247f6a70ea6faa > Signed-off-by: Sreedhar Sambangi > --- >

Re: [PATCH v12 8/9] add TC G210 platform driver

On Mon, Apr 04, 2016 at 11:48:23AM +0100, Joao Pinto wrote: > > Hi Rob, > > On 4/4/2016 6:15 AM, Rob Herring wrote: > > On Thu, Mar 31, 2016 at 07:57:21PM +0100, Joao Pinto wrote: > >> This patch adds a glue platform driver for the Synopsys G210 Test Chip. > >> > >> Signed-off-by: Joao Pinto >

Re: [PATCH 1/2] qcom: ipq4019: Add regulator support to DK04 device tree

On Mon, Apr 04, 2016 at 02:08:10PM -0700, Sreedhar Sambangi wrote: > This adds the regulator nodes to DK04 device tree to support > > Change-Id: I9c1df0e720a330bf6db1889fd2247f6a70ea6faa > Signed-off-by: Sreedhar Sambangi > --- > .../bindings/regulator/ipq4019-regulator.txt | 19 >

<    3   4   5   6   7   8   9   10   11   12   >