On Thu, Feb 4, 2021 at 7:47 AM Arnd Bergmann wrote:
>
> Enlarging the size of 'struct btmtk_hci_wmt_cmd' makes it no longer
>
> Unfortunately, I could not figure out why the message size is
> increased in the previous patch. Using dynamic allocation means
That patch appears to be have been split
.8 and I can find no adapters for which it
is not correct. And even if there is an adapter for which this does not
work, the current behavior would be to fall back to alt 0, which can not
possibly work either, and so is no better.
Signed-off-by: Trent Piepho
---
drivers/bluetooth/btusb.c
On Tuesday, December 8, 2020 5:13:36 PM PST Pali Rohár wrote:
> On Tuesday 08 December 2020 15:04:29 Trent Piepho wrote:
> > Does this also give userspace a clear point at which to determine MTU
setting,
> > _before_ data is sent over SCO connection? It will not work if
On Wednesday, September 23, 2020 3:22:15 AM PST Pali Rohár wrote:
> On Monday 14 September 2020 20:18:27 Joseph Hwang wrote:
> > On Thu, Sep 10, 2020 at 4:18 PM Pali Rohár wrote:
> > > And this part of code which you write is Realtek specific.
> >
> > We currently only have Intel and Realtek plat
On Wed, Sep 30, 2020 at 2:47 AM Tony Lindgren wrote:
>
> * Trent Piepho [200930 09:34]:
> >
> > Where do these flags go? In pinctrl-single,pins? Like:
> >
> > pinctrl-single,pins = ;
> >
> > But PIN_INPUT_PULLUP is a generic flag? Which is transla
On Wed, Sep 30, 2020 at 2:15 AM Tony Lindgren wrote:
>
> * Trent Piepho [200930 08:35]:
> > The closest thing would be the generic pin config type bindings, which
> > go in the pinctrl driver's nodes, and look like this:
> > &am335x_pinmux {
> > pinctrl
On Tue, Sep 29, 2020 at 10:15 PM Tony Lindgren wrote:
> * Trent Piepho [200929 20:16]:
> > On Thu, Sep 24, 2020 at 12:04 AM Tony Lindgren wrote:
> > > Certainly different compatible strings can be used as needed.
> > > But pinctrl-single is not going to be am335x
On Thu, Sep 24, 2020 at 12:04 AM Tony Lindgren wrote:
>
> * Trent Piepho [200924 06:31]:
> > > >
> > > > The pinctrl-single driver? How will that work with boards that are
> > > > not am335x and don't use conf and mux fields in the same manner as
On Wed, Sep 23, 2020 at 11:06 PM Tony Lindgren wrote:
>
> * Trent Piepho [200924 05:49]:
> > On Wed, Sep 23, 2020 at 10:43 PM Tony Lindgren wrote:
> > >
> > > * Trent Piepho [200924 01:34]:
> > > > On Tue, Sep 22, 2020 at 11:57 PM Tony Lindgren wrote
On Wed, Sep 23, 2020 at 10:43 PM Tony Lindgren wrote:
>
> * Trent Piepho [200924 01:34]:
> > On Tue, Sep 22, 2020 at 11:57 PM Tony Lindgren wrote:
> > >
> > > Also FYI, folks have also complained for a long time that the
> > > pinctrl-single
> > &
On Tue, Sep 22, 2020 at 11:57 PM Tony Lindgren wrote:
>
> Also FYI, folks have also complained for a long time that the pinctrl-single
> binding mixes mux and conf values while they should be handled separately.
>
Instead of combining two fields when the dts is generated they are now
combined whe
On Thu, Sep 17, 2020 at 2:20 AM Drew Fustini wrote:
>
> On Thu, Sep 17, 2020 at 02:03:46AM -0700, Trent Piepho wrote:
> > On Mon, Sep 14, 2020 at 3:44 AM Drew Fustini wrote:
> > >
> > > +
> > > +When #pinctrl-cells = 2, then setting a pin
On Mon, Sep 14, 2020 at 3:44 AM Drew Fustini wrote:
>
> +
> +When #pinctrl-cells = 2, then setting a pin for a device could be done with:
> +
> + pinctrl-single,pins = <0xdc 0x30 0x07>;
> +
> +Where 0x30 is the pin configuration value and 0x07 is the pin mux mode value.
> +See the device exa
On Tuesday, June 30, 2020 6:33:20 PM PDT Drew Fustini wrote:
> Increase #pinctrl-cells to 2 so that mux and conf be kept separate. This
> requires the AM33XX_PADCONF macro in omap.h to also be modified to keep pin
> conf and pin mux values separate.
> --- a/arch/arm/boot/dts/am33xx-l4.dtsi
> +++ b
On Tuesday, June 30, 2020 6:33:19 PM PDT Drew Fustini wrote:
> If "pinctrl-single,pins" has 3 arguments (offset, conf, mux), then
> pcs_parse_one_pinctrl_entry() does an OR operation on conf and mux to
> get the value to store in the register.
> - vals[found].val = pinctrl_spec.args[1
On Mon, 2019-09-09 at 20:19 +0300, Vitaly Gaiduk wrote:
> This patch adds ability to switch beetween two PHY SGMII modes.
> Some hardware, for example, FPGA IP designs may use 6-wire mode
> which enables differential SGMII clock to MAC.
>
> +
> + val = phy_read_mmd(phydev, DP83867_DEVA
On Thu, 2019-09-05 at 19:26 +0300, Vitaly Gaiduk wrote:
> Add documentation of ti,sgmii-type which can be used to select
> SGMII mode type (4 or 6-wire).
>
> Signed-off-by: Vitaly Gaiduk
> ---
> Documentation/devicetree/bindings/net/ti,dp83867.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> dif
On Fri, 2019-08-23 at 17:57 +0800, Biwen Li wrote:
> The patch supports flextimer for lx2160a
>
> Signed-off-by: Biwen Li
> ---
> drivers/rtc/rtc-fsl-ftm-alarm.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/rtc/rtc-fsl-ftm-alarm.c b/drivers/rtc/rtc-fsl-
> ftm-alarm.c
> index
On Fri, 2019-07-19 at 02:57 +, Anson Huang wrote:
>
> > I do worry that handling the irq before the rtc device is registered could
> > still
> > result in a crash. From what I saw, the irq path in snvs only uses driver
> > state
> > members that are fully initialized for the most part, and
On Thu, 2019-07-18 at 03:08 +, Aisheng Dong wrote:
> > From: Anson Huang
> > Sent: Wednesday, July 17, 2019 9:58 PM>
> > Hi, Aisheng
> >
> > > > From: anson.hu...@nxp.com
> > > > Sent: Tuesday, July 16, 2019 3:19 PM
> > > >
> > > > The RTC IRQ is requested before the struct rtc_device is
>
On Tue, 2019-06-25 at 21:19 +0200, Alexandre Belloni wrote:
> On 25/06/2019 17:16:52+0000, Trent Piepho wrote:
> > On Tue, 2019-06-25 at 11:29 +0200, Alexandre Belloni wrote:
> > > Userspace is certainly adjusting the timezone after the kernel did. Can
> > > you ru
On Tue, 2019-06-25 at 11:29 +0200, Alexandre Belloni wrote:
>
>
> Userspace is certainly adjusting the timezone after the kernel did. Can
> you run the same commands without running your init?
>
> On stable, you have /etc/init.d/hwclock.sh that still runs and does the
> correct thing. My unders
On Tue, 2019-06-11 at 17:32 -0300, Fabio Estevam wrote:
> Hi Anson,
>
> On Tue, Jun 11, 2019 at 3:31 AM wrote:
> >
> > From: Anson Huang
> >
> > i.MX system controller RTC driver can support all i.MX SoCs
> > with system controller inside, this patch makes the compatible
> > string more generi
On Mon, 2019-05-13 at 22:46 +0200, Andrew Lunn wrote:
> > > Perhaps you could tell me if the approach I've taken in patch 3,
> > > "Add ability to disable output clock", and patch 4, "Disable tx/rx
> > > delay when not configured", are considered acceptable? I can conceive
> > > of arguments for
The variables used to store u32 DT properties were signed ints. This
doesn't work properly if the value of the property were to overflow.
Use unsigned variables so this doesn't happen.
Cc: Andrew Lunn
Cc: Florian Fainelli
Cc: Heiner Kallweit
Signed-off-by: Trent Piepho
---
drive
Cc: Heiner Kallweit
Signed-off-by: Trent Piepho
---
drivers/net/phy/dp83867.c | 36 ++--
1 file changed, 26 insertions(+), 10 deletions(-)
diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index fd35131a0c39..420729cd6025 100644
--- a/drivers/net/phy
g "rgmii" mode.
Cc: Andrew Lunn
Cc: Florian Fainelli
Cc: Heiner Kallweit
Signed-off-by: Trent Piepho
---
drivers/net/phy/dp83867.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index 420729cd6025..a46cc9427fb3 100644
--- a/dr
On Wed, 2019-05-01 at 16:25 +0200, Alexandre Belloni wrote:
> On 30/04/2019 22:31:19+0000, Trent Piepho wrote:
> > On Tue, 2019-04-30 at 22:18 +0200, Alexandre Belloni wrote:
> > > The RTC core already ensures the alarm is set to a time in the future, it
> > > is not
On Tue, 2019-04-30 at 22:18 +0200, Alexandre Belloni wrote:
> The RTC core already ensures the alarm is set to a time in the future, it
> is not necessary to check again in the driver.
My reading of the rtc core code is that it checks if the alarm is in
the future *twice* before handing off the se
On Mon, 2019-04-29 at 07:02 +, Anson Huang wrote:
> Use __maybe_unused for power management related functions
> instead of #if CONFIG_PM_SLEEP to simply the code.
>
> Signed-off-by: Anson Huang
This will result in the functions always being included, even if
PM_SLEEP is off...
>
> @@ -387
more complex comparison (d0*dp > d1*d) is used.
I also wrote some comments explaining the code. While one still needs
to look up the math elsewhere, they should help a lot to follow how the
code relates to that math.
Cc: Oskar Schirmer
Signed-off-by: Trent Piepho
---
lib
On Wed, 2019-02-27 at 10:55 +0900, Jiada Wang wrote:
> Hi Trent
>
> Thanks for reporting
Thanks for the information, it was very helpful!
>
> in the commit message of commit ("spi: imx: Add support for SPI Slave
> mode"), it mentions
>
> "The stale data in RXFIFO will be dropped when the Slav
On Fri, 2019-03-01 at 00:55 -0800, Andrey Smirnov wrote:
> The clock in question is not present on i.MX7, so move the code
> requesting it into i.MX8MQ-only path.
>
> Fixes: eeb61c4e8530 ("PCI: imx6: Add code to request/control
> "pcie_aux" clock for i.MX8MQ
On Tue, 2019-02-12 at 10:36 +0100, Lucas Stach wrote:
> Am Montag, den 11.02.2019, 17:51 -0800 schrieb Andrey Smirnov:
> > PCIe IP block has additional clock, "pcie_aux", that needs to be
> > controlled by the driver. Add code to support that.
This breaks iMX7d.
> >
> > @@ -1049,6 +1059,12 @@ st
On Tue, 2017-09-05 at 14:12 +0900, Jiada Wang wrote:
> Previously i.MX SPI controller only works in Master mode.
> This patch adds support to i.MX51, i.MX53 and i.MX6 ECSPI
> controller to work also in Slave mode.
Recently DMA has been enabled for imx6/7 with SPI. This results in
memory corruptio
On Mon, 2019-02-25 at 16:15 +, Leonard Crestez wrote:
> On Mon, 2019-02-25 at 17:02 +0100, Stefan Agner wrote:
> > Define the length of the DBI registers and limit config space to its
> > length. This makes sure that the kernel does not access registers
> > beyond that point, avoiding the follo
On Tue, 2019-02-12 at 22:57 -0200, Fabio Estevam wrote:
> On Tue, Feb 12, 2019 at 10:07 PM Trent Piepho
> wrote:
>
> > Tried SDMA firmware 4.2. Still broken. No apparent change.
> >
> > Get 4 cycle pause after each byte.
> >
> > And crash while/after
On Tue, 2019-02-12 at 17:37 -0200, Fabio Estevam wrote:
> On Mon, Feb 11, 2019 at 8:22 PM Trent Piepho
> wrote:
>
> > > Just trying to understand if the SDMA firmware plays a role on
> > > this
> > > behavior or not.
> >
> > The ROM firmwar
On Mon, 2019-02-11 at 19:34 -0200, Fabio Estevam wrote:
> Hi Trent,
>
> On Mon, Feb 11, 2019 at 6:44 PM Trent Piepho wrote:
>
> > I've had more time to test.
> >
> > Without DMA, I can reload my FPGA hundreds of times and get days of
> > uptime using
On Mon, 2019-02-11 at 09:23 +0800, Shawn Guo wrote:
> On Thu, Feb 07, 2019 at 09:00:44PM +0000, Trent Piepho wrote:
> > On Mon, 2019-01-07 at 14:22 +0100, Stefan Agner wrote:
> > > Allow to use DMA for SPI by adding the appropriate DMA properites
> > > to the ecspi nod
On Mon, 2019-01-07 at 14:22 +0100, Stefan Agner wrote:
> Allow to use DMA for SPI by adding the appropriate DMA properites
> to the ecspi nodes.
>
> Signed-off-by: Stefan Agner
> ---
> arch/arm/boot/dts/imx7s.dtsi | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dt
On Thu, 2019-02-07 at 16:39 +0530, Kishon Vijay Abraham I wrote:
> Now that Keystone started using it's own msi_irq_chip, remove
> Keystone specific callback function defined in dw_pcie_host_ops.
>
> @@ -209,9 +195,6 @@ static void dw_pci_bottom_ack(struct irq_data *d)
>
> dw_pcie_wr_own_c
On Fri, 2018-12-21 at 04:33 +, Richard Zhu wrote:
> The MSI Enable bit in the MSI Capability (PCIe r4.0, sec 7.7.1.2)
> controls whether a Function can request service using MSI.
>
> i.MX6 Root Ports implement the MSI Capability and may use MSI to
> request service for events like PME, hotplug
On Thu, 2018-12-20 at 23:27 -0800, Andrey Smirnov wrote:
> Until commit 4d107d3b5a68 ("PCI: imx6: Move link up check into
> imx6_pcie_wait_for_link()") the driver relied on both LINK_UP and
> LINK_IN_TRAINING to determine if PCIE link was up.
I've already got a patch in that fixed this issue. Que
On Wed, 2018-12-19 at 16:47 -0800, Andrey Smirnov wrote:
>
> > > This series initially added explicit offsets but I suggested a single
> > > "controller-id" because:
> > > * There are multiple bit and byte offsets
> > > * Other imx8 SOCs also have 2x pcie with other bit/byte offsets
> > >
> >
On Tue, 2018-12-18 at 16:04 -0500, Sven Van Asbroeck wrote:
> We are using a Broadcom BCM57780 ethernet adapter (Tigon3) connected
> to a i.MX6 PCIe controller. On a Freescale i.MX6 SoC.
>
> This combo worked ok on mainline v4.17.
> On mainline v4.18-rc1, a regression was introduced that caused a
On Thu, 2018-12-06 at 11:28 +0100, Lucas Stach wrote:
> Am Mittwoch, den 05.12.2018, 23:45 -0800 schrieb Andrey Smirnov:
> > Building a kernel with CONFIG_PCI_IMX6=y, but CONFIG_PCIEPORTBUS=n
> > produces a system where built-in PCIE bridge (16c3:abcd) isn't
> > bound
> > to pcieport driver. This,
On Wed, 2018-11-28 at 19:52 +, Robin Murphy wrote:
> On 28/11/2018 18:56, Trent Piepho wrote:
> > On Wed, 2018-11-28 at 16:16 +, Robin Murphy wrote:
> > >
> > > >
> > > > +static int imx6q_pcie_abort_handler_thumb2(unsigned long addr,
> &
On Wed, 2018-11-28 at 16:16 +, Robin Murphy wrote:
>
> >
> > +static int imx6q_pcie_abort_handler_thumb2(unsigned long addr,
> > + unsigned int fsr, struct pt_regs *regs)
> > +{
> > + unsigned long pc = instruction_pointer(regs);
> > + unsigned long instr = *(unsigned long *)p
On Mon, 2018-11-26 at 10:16 +, Leonard Crestez wrote:
> On Tue, 2018-11-20 at 21:42 +0100, Stefan Agner wrote:
> > On 20.11.2018 20:13, Trent Piepho wrote:
> > > On Tue, 2018-11-20 at 18:19 +, Leonard Crestez wrote:
> > > > On Tue, 2018-11-20 at 1
On Tue, 2018-11-20 at 21:42 +0100, Stefan Agner wrote:
> On 20.11.2018 20:13, Trent Piepho wrote:
> >
> > On IMX7d, there are significant blocks of 00s in the config space, and
> > all 0xff at 0xb50 on up.
> >
> > I.e., significant portions are empty, in the mi
On Tue, 2018-11-20 at 18:19 +, Leonard Crestez wrote:
> On Tue, 2018-11-20 at 17:56 +0100, Stefan Agner wrote:
> > Define the length of the DBI registers. This makes sure that
> > the kernel does not access registers beyond that point, avoiding
> > the following abort on a i.MX 6Quad:
> > # c
On Mon, 2018-11-19 at 10:41 +0100, Stefan Agner wrote:
>
>
> +static const struct imx6_pcie_drvdata imx6q_pcie_drvdata = {
> + .variant = IMX6Q,
> + .dbi_length = 0x15c,
> +};
> +
> +static const struct imx6_pcie_drvdata imx6sx_pcie_drvdata = {
> + .variant = IMX6SX,
> +};
> +
> +sta
On Sat, 2018-11-17 at 10:12 -0800, Andrey Smirnov wrote:
> PCIE PHY IP block on i.MX7D differs from the one used on i.MX6 family,
> so none of the code in current implementation of imx6_pcie_reset_phy()
> is applicable.
Tested on IMX7d, still appears to work.
Note that your patches will collide w
updating this for v4.20-rc2, tested on IMX 7d, config space
access works as before.
Tested-by: Trent Piepho
Signed-off-by: Trent Piepho
---
Changes from v1:
Ported to current kernel
drivers/pci/controller/dwc/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/dwc/Kconfig
b/drivers/pci/controller/dwc/Kconfig
index 91b0194240a5..6aafec3fad00 100644
The Linux i2c layer has functions to execute common SMBUS/I2C
transactions. The register access code here is identical to the I2C
read/write block data routines.
Cc: Alessandro Zummo
Cc: Alexandre Belloni
Signed-off-by: Trent Piepho
---
drivers/rtc/rtc-isl1208.c | 37
On Wed, 2018-11-14 at 16:49 +0100, Stefan Agner wrote:
> On 19.10.2018 13:13, Stefan Agner wrote:
> > Reading the full 4k config space through sysfs leads to an
> > external abort. Testing on a platform showed that the upper
> > limit is 512. Limit config space to 512.
>
> Any comment on this patc
On Thu, 2018-11-01 at 17:30 -0400, thesve...@gmail.com wrote:
> I am seeing this in my kernel log:
>
> [ 10.235625] tg3 :03:00.0 eth20: No interrupt was generated
> using MSI.
> Switching to INTx mode. Please report this failure to the PCI
> maintainer and include system chipset
On Tue, 2018-10-16 at 10:03 +0100, Mark Brown wrote:
> On Mon, Oct 15, 2018 at 06:34:18PM +0000, Trent Piepho wrote:
>
> > What about the calls to spi->controller->set_cs() after this? Should a
> > driver provided set_cs method be responsible for checking SPI_NO_CS?
On Fri, 2018-10-12 at 10:23 +0100, Phil Elwell wrote:
> The SPI configuration state includes an SPI_NO_CS flag that disables
> all CS line manipulation, for applications that want to manage their
> own chip selects. However, this flag is ignored by the GPIO CS code
> in the SPI framework.
> @@ -72
On Wed, 2018-10-10 at 13:27 +0100, Mark Brown wrote:
>
> That's great and we get to reuse all the driver code with a quirk (a
> quirk which fixes the hardware to be more compatible with devices, this
> is a really good hardware change). Ideally we'd be able to enumerate
> things like IP versions
On Wed, 2018-10-10 at 10:08 +0300, Talel Shenhar wrote:
>
> The dw spi controller has an auto-deselect of Chip-Select, in case there is
> no data inside the Tx FIFO. While working on platforms with Alpine chips,
> auto-deselect mode causes an issue for some spi devices that can't handle
> the Chip
On Wed, 2018-10-10 at 18:15 +0300, Talel Shenhar wrote:
> Add support for a new devicetree compatible string called
> 'al,alpine-apb-ssi', which is necessary for the Amazon Alpine spi
> controller. 'al,alpine-dw-apb-ssi' is used in the dw spi driver if
> specified in the devicetree. Otherwise, fal
On Wed, 2018-10-10 at 15:40 +0200, Geert Uytterhoeven wrote:
> Currently EEPROM writes are implemented using a single SPI transfer,
> which contains all of command, address, and payload data bytes.
> As some SPI controllers impose limitations on transfers with respect to
> the use of DMA, they may
On Mon, 2018-09-24 at 10:13 -0700, Doug Anderson wrote:
> IIUC previous suggestions about just naming it based on the first SoC
> was due to the difficulty of coming up with a good generic name to
> give something. For instance you definitely wouldn't want to name it
> "qcom-qspi-sdm8xx" because y
On Fri, 2018-09-21 at 10:39 -0700, Mark Brown wrote:
> On Fri, Sep 21, 2018 at 10:30:57AM -0700, Stephen Boyd wrote:
> > Quoting Ryan Case (2018-09-20 15:40:54)
> > > +Required properties:
> > > +- compatible: Should contain:
> > > + "qcom,sdm845-qspi"
> > Does someone have a more ge
If driver_override was set when a device was released the string would
not be kfree'ed in amba_device_release and thus leaked when the amba
device was freed.
Cc: Russell King
Cc: Todd Kjos
Cc: Geert Uytterhoeven
Cc: Greg Kroah-Hartman
Signed-off-by: Trent Piepho
---
drivers/amba/bus.
On Fri, 2018-08-17 at 09:01 +0200, Simon Goldschmidt wrote:
> The spi-dw driver currently only supports 8 or 16 bits per word.
>
> Since the hardware supports 4-16 bits per word, adapt the driver
> to also support this.
>
>
> @@ -307,15 +307,13 @@ static int dw_spi_transfer_one(struct spi_contr
On Thu, 2018-08-09 at 12:37 -0700, Doug Anderson wrote:
> On Thu, Aug 9, 2018 at 11:24 AM, Trent Piepho wrote:
> >
> I think we're in agreement but perhaps there's a miscommunication here?
>
> I'm saying that we _shouldn't_ put the max-speed of the maste
On Fri, 2018-08-10 at 21:59 +0530, dk...@codeaurora.org wrote:
>
> Here are my couple of cents:
> SPI controller maximum frequency can be lesser than or equal to Clock
> framework's maximum
> frequency, so should not rely on the Clock framework.
But there is probably some means, via the controll
On Thu, 2018-08-09 at 11:03 -0700, Doug Anderson wrote:
> On Fri, Aug 3, 2018 at 5:18 AM, wrote:
> > > > + if (of_property_read_u32(pdev->dev.of_node, "spi-max-frequency",
> > > > + &spi->max_speed_hz)) {
> >
> >
> > > Why does this need to come from DT?
> >
On Wed, 2018-08-08 at 11:19 +0800, Baolin Wang wrote:
> On 8 August 2018 at 01:10, Trent Piepho wrote:
> > On Tue, 2018-08-07 at 18:43 +0800, Baolin Wang wrote:
> > >
> > > +static u32 sprd_spi_transfer_max_timeout(struct sprd_spi *ss,
> > > +
On Wed, 2018-08-08 at 11:54 +0100, Mark Brown wrote:
> On Wed, Aug 08, 2018 at 06:35:28PM +0800, Baolin Wang wrote:
> > On 8 August 2018 at 17:50, Mark Brown wrote:
> > > Right, I don't think we added this yet (if we did I can't see
> > > it). I'd
> > > add a new field to spi_transfer for this, t
On Tue, 2018-08-07 at 18:43 +0800, Baolin Wang wrote:
>
> +static u32 sprd_spi_transfer_max_timeout(struct sprd_spi *ss,
> + struct spi_transfer *t)
> +{
> + /*
> + * The time spent on transmission of the full FIFO data is the maximum
> + * SPI tr
On Thu, 2018-07-26 at 11:46 +0300, Andy Shevchenko wrote:
> > +
> > + /*
> > +* the supported rates are even numbers from 4 to 254. (4,6,8...254)
> > +* round up as we look for equal or less speed
> > +*/
> > + ckrat = DIV_ROUND_UP(clk_get_rate(priv->clk), speed)
On Thu, 2018-07-19 at 15:51 +0900, Keiji Hayashibara wrote:
>
> +config SPI_UNIPHIER
> + tristate "Socionext UniPhier SPI Controller"
> + depends on (ARCH_UNIPHIER || COMPILE_TEST) && OF
> + help
> + This driver supports the SPI controller on Socionext
> + UniPhier SoCs.
P
On Thu, Jul 5, 2018 at 6:06 AM, Gustavo A. R. Silva
wrote:
> Add suffix ULL to constant 256 in order to give the compiler complete
> information about the proper arithmetic to use.
>
> Notice that such constant is used in a context that expects an
> expression of type u64 (64 bits, unsigned) and t
On Fri, 2018-05-18 at 19:22 -0400, Theodore Y. Ts'o wrote:
> On Fri, May 18, 2018 at 10:56:18PM +0000, Trent Piepho wrote:
> >
> > Let's look at what we're doing after this fix:
> > Want non-cryptographic random data for UUID, ask kernel for it.
> > Kerne
On Thu, 2018-05-17 at 22:32 -0400, Theodore Y. Ts'o wrote:
> On Fri, May 18, 2018 at 01:27:03AM +0000, Trent Piepho wrote:
> > I've hit this on an embedded system. mke2fs hangs trying to format a
> > persistent writable filesystem, which is where the random seed to
Since I wasn't on this thread from the start, I can only find a way to
reply to message in mbox format on patchwork, and this seemed the best.
On Fri, 2018-04-27 at 16:10 -0400, Theodore Tso wrote:
>
>
> This is why ultimately, we do need to attack this problem from both
> ends, which means teac
ve people to see if they care. In a few cases people do, but
> > > most often no one does.
> >
> > Let's start with this one (zoran) then, as Mauro is keen on having
> > all media drivers compile-testable on x86-64 and arm.
> >
> > Trent Piep
On Thu, 2018-03-29 at 02:53 +0100, Bryan O'Donoghue wrote:
> On 29/03/18 01:12, Trent Piepho wrote:
>
> > I sent a patch a couple weeks ago that addressed a similar issue, see
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.ozlabs.org%2Fpa
On Wed, 2018-03-28 at 20:14 +0100, Bryan O'Donoghue wrote:
> commit 179a502f8c46 ("rtc: snvs: add Freescale rtc-snvs driver") introduces
> the SNVS RTC driver with a function snvs_rtc_enable().
>
> snvs_rtc_enable() can return an error on the enable path however this
> driver does not currently tr
more arithmetic operations.
Signed-off-by: Trent Piepho
---
drivers/spi/spi-bcm2835aux.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c
index 7428091d3f5b..1431cb98fe40 100644
--- a/drivers/spi/spi
On Wed, 2018-02-07 at 10:00 -0600, Gustavo A. R. Silva wrote:
> Add suffix ULL to constant 9 in order to give the compiler complete
> information about the proper arithmetic to use. Notice that this
> constant is used in a context that expects an expression of type
> unsigned long long (64 bits, un
On Tue, 2018-01-02 at 11:22 +0100, Ludovic Desroches wrote:
> On Wed, Dec 27, 2017 at 10:40:00PM +0100, Cyrille Pitchen wrote:
>
> > Or maybe no change at all is required at the at_xdmac.c driver side: we
> > just don't care about the provided flags in the "dmas" property, especially
> > the "peri
On Fri, 2017-12-29 at 15:46 +0530, Vignesh R wrote:
> On Friday 29 December 2017 12:24 AM, Trent Piepho wrote:
> >
> > > Vignesh has suggested to call virt_addr_valid() instead.
> > > I think Boris has also told me about this function.
> > > So it might be t
On Thu, 2017-12-28 at 11:39 +0100, Cyrille Pitchen wrote:
> Le 26/12/2017 à 20:43, Trent Piepho a écrit :
> > On Sun, 2017-12-24 at 05:36 +0100, Cyrille Pitchen wrote:
> > >
> > > Then the patch adds two hardware capabilities for SPI flash controllers,
>
On Wed, 2017-12-27 at 10:36 +, Mark Brown wrote:
> On Tue, Dec 26, 2017 at 06:45:28PM +0000, Trent Piepho wrote:
>
> > Or, since this only fixes instances of DMA-unsafe buffers used in
> > access to SPI NOR flash chips, and since there are other SPI master
> > int
On Sun, 2017-12-24 at 05:36 +0100, Cyrille Pitchen wrote:
>
> Then the patch adds two hardware capabilities for SPI flash controllers,
> SNOR_HWCAPS_WR_BOUNCE and SNOR_HWCAPS_RD_BOUNCE.
Are there any drivers for which a bounce buffer is NOT needed when the
tx/rx buffer is not in DMA safe memory?
On Sun, 2017-12-24 at 05:36 +0100, Cyrille Pitchen wrote:
> this series tries to solve a long time issue of compatibility between the
> MTD and SPI sub-systems about whether we should use DMA-safe memory.
Can this should replace SoC specific fixes like:
c687c46e9e45
spi: spi-ti-qspi: Use bounce b
On Thu, 2017-12-21 at 14:03 -0600, Kyle Roeschley wrote:
> Add a sysfs interface to instantiate and delete SPI devices using the
> spidev driver. This can be used when developing a driver on a
> self-soldered board which doesn't yet have proper SPI device declaration
> at the platform level, and pr
On Wed, 2017-11-15 at 18:35 +0200, Radu Pirea wrote:
> If the cache model is VIVT, DMA data transfers may not be valid and to
> ensure the validity of the data cache must be flushed and invalidated.
>
> Signed-off-by: Radu Pirea
>
> +#ifdef CONFIG_SOC_SAM_V4_V5
> + /*
> + * On Atmel So
On Thu, 2016-07-28 at 10:21 -0500, atull wrote:
> > >
> > > This isn't going work if more than one bridge is used. Each bridge has
> > > its own priv and thus priv->l3_remap_value. Each bridge's priv will
> > > have just the bit for it's own remap set. The 2nd bridge to be enabled
> > > will tur
On Mon, 2016-06-13 at 14:35 -0500, atull wrote:
> > > +
> > > + /* Allow bridge to be visible to L3 masters or not */
> > > + if (priv->remap_mask) {
> > > + priv->l3_remap_value |= ALT_L3_REMAP_MPUZERO_MSK;
> >
> > Doesn't seem like this belongs here. I realize the write-only register
>
On Fri, 2016-02-05 at 15:30 -0600, at...@opensource.altera.com wrote:
> Supports Altera SOCFPGA bridges:
> * fpga2sdram
> * fpga2hps
> * hps2fpga
> * lwhps2fpga
>
> Allows enabling/disabling the bridges through the FPGA
> Bridge Framework API functions.
I'm replying to v16 because it exists o
On Sat, 2016-04-30 at 11:48 +0100, Russell King - ARM Linux wrote:
> On Fri, Apr 29, 2016 at 06:42:35PM -0400, Javier Martinez Canillas wrote:
> > Maybe a third opinion could make this conversation constructive again.
And maybe a forth.
> > I think Doug's point is that using a UUID or labels for
On Wed, 2016-03-09 at 11:13 +0100, Maxime Ripard wrote:
> On Tue, Mar 08, 2016 at 11:24:33PM +0000, Trent Piepho wrote:
> > I think maybe the problem isn't here isn't clear. For some boards
> > (mxs), only part of a MAC address is stored in nvmem while the rest of
>
On Tue, 2016-03-08 at 14:46 -0800, Andrey Smirnov wrote:
> >> I don't think I understand what you mean, could you give me an example
> >> of how I'd use local-mac-address property for that use case? AFAIK,
> >> local-mac-address is just an array of bytes embedded into device tree,
> >
> > Well, yea
1 - 100 of 165 matches
Mail list logo
