does not attempt to read if not data is requested.
Signed-off-by: Jorge Ramirez-Ortiz
---
v2: tidy up the while loop to avoid reading when no data is requested
drivers/char/hw_random/optee-rng.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/char/hw_random/optee
Allow OP-TEE to specify the number of retries in the adaptor.
Signed-off-by: Jorge Ramirez-Ortiz
---
drivers/tee/optee/rpc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/tee/optee/rpc.c b/drivers/tee/optee/rpc.c
index 1e3614e4798f..2d46a9ecb1de 100644
--- a/drivers/tee
The invalid definition in the supply causes the Qualcomm's EVB-1000
and EVB-4000 not to boot.
Fix the boot issue by correctly defining the supply: vdd_s3 (namely
"vdd_apc") is actually connected to vph_pwr.
Reported-by: Niklas Cassel
Tested-by: Jorge Ramirez-Ortiz
Signed-off-by
Remove unnecessary condition check and associated goto.
Signed-off-by: Jorge Ramirez-Ortiz
---
drivers/spi/spi-qup.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c
index 974a8ce58b68..314d91b95a16 100644
--- a/drivers/spi/spi-qup.c
+++ b
) to add new functions to the Qualcomm 64bit yielding
call interface.
Signed-off-by: Jorge Ramirez-Ortiz
---
drivers/firmware/qcom_scm-64.c | 48 ++
1 file changed, 25 insertions(+), 23 deletions(-)
diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware
be the binding agreement.
Jorge Ramirez-Ortiz (2):
dt-bindings: Add Qualcomm USB SuperSpeed PHY bindings
phy: qualcomm: usb: Add SuperSpeed PHY driver
.../bindings/usb/qcom,usb-ssphy.txt | 74
drivers/phy/qualcomm/Kconfig | 11 +
drivers/phy/qu
Controls Qualcomm's SS phy 1.0.0 implemented in the QCS404 and some
other Qualcomm platforms.
Based on Sriharsha Allenki's original code.
Signed-off-by: Jorge Ramirez-Ortiz
---
drivers/phy/qualcomm/Kconfig | 11 +
drivers/phy/qualcomm/Makefile | 1 +
drivers/ph
Binding description for Qualcomm's 1.0.0 SuperSpeed phy controller
embedded in QCS404.
Based on Sriharsha Allenki's original
definitions.
Signed-off-by: Jorge Ramirez-Ortiz
---
.../bindings/usb/qcom,usb-ssphy.txt | 74 +++
1 file changed, 74 insertions(
El Wed, 15 Apr 2020 00:00:20 +0200
Hauke Mehrtens escribió:
> On 4/4/20 10:53 AM, Jorge Amoros-Argos wrote:
> > Dear community,
> >
> > This is addresed to the Lantiq/Intel developers for the SoC's
> > VRX200 and XWAY in general.
> >
> > I'm
clude this as an entry of the /proc/?
Thanks for reading,
Jorge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On 01/06/20, Sumit Garg wrote:
> Hi Jorge,
hey
>
> On Mon, 1 Jun 2020 at 04:41, Jorge Ramirez-Ortiz wrote:
> >
> > Some secure elements like NXP's SE050 sit on I2C buses. For OP-TEE to
> > control this type of cryptographic devices it needs coordinated access
&
On 12/08/20, Jens Wiklander wrote:
> On Tue, Aug 11, 2020 at 07:55:31PM +0200, Jorge Ramirez-Ortiz wrote:
> > Some secure elements like NXP's SE050 sit on I2C buses. For OP-TEE to
> > control this type of cryptographic devices it needs coordinated access
> > to
On 22/07/20, Jorge Ramirez-Ortiz wrote:
> Some secure elements like NXP's SE050 sit on I2C buses. For OP-TEE to
> control this type of cryptographic devices it needs coordinated access
> to the bus, so collisions and RUNTIME_PM dont get in the way.
>
> This trampoline dr
On 23/07/20, Jorge Ramirez-Ortiz wrote:
> The current code waits for data to be available before attempting a
> second read. However the second read would not be executed as the
> while loop exits.
>
> This fix does not wait if all data has been read and reads a second
> time if
On 05/08/20, Jens Wiklander wrote:
> On Wed, Aug 05, 2020 at 03:35:01PM +0200, Jorge Ramirez-Ortiz, Foundries
> wrote:
> > On 22/07/20, Jorge Ramirez-Ortiz wrote:
> > > Some secure elements like NXP's SE050 sit on I2C buses. For OP-TEE to
> > > control this typ
On 05/08/20, Sumit Garg wrote:
> Apologies for my delayed response as I was busy with some other tasks
> along with holidays.
no pb! was just making sure this wasnt falling through some cracks.
>
> On Fri, 24 Jul 2020 at 19:53, Jorge Ramirez-Ortiz, Foundries
> wrote:
> >
&
On 06/08/20, Sumit Garg wrote:
> On Thu, 6 Aug 2020 at 02:08, Jorge Ramirez-Ortiz, Foundries
> wrote:
> >
> > On 05/08/20, Sumit Garg wrote:
> > > Apologies for my delayed response as I was busy with some other tasks
> > > along with holidays.
> >
On 06/08/20, Sumit Garg wrote:
> On Thu, 6 Aug 2020 at 12:00, Jorge Ramirez-Ortiz, Foundries
> wrote:
> >
> > On 06/08/20, Sumit Garg wrote:
> > > On Thu, 6 Aug 2020 at 02:08, Jorge Ramirez-Ortiz, Foundries
> > > wrote:
> > > >
> > > &g
On 08/02/21, Jens Wiklander wrote:
> Hi Jorge,
>
> On Wed, Jan 27, 2021 at 11:41 AM Jens Wiklander
> wrote:
> >
> > Hi Arnd,
> >
> > On Mon, Jan 25, 2021 at 12:38 PM Arnd Bergmann wrote:
> > >
> > > From: Arnd Bergmann
> > >
> &
On 08/02/21, Jorge Ramirez-Ortiz, Foundries wrote:
> On 08/02/21, Jens Wiklander wrote:
> > Hi Jorge,
> >
> > On Wed, Jan 27, 2021 at 11:41 AM Jens Wiklander
> > wrote:
> > >
> > > Hi Arnd,
> > >
> > > On Mon, Jan 25, 2021 at 12:
On 26/01/21, Arnd Bergmann wrote:
> On Tue, Jan 26, 2021 at 9:08 AM Jorge Ramirez-Ortiz, Foundries
> wrote:
> >
> > On 25/01/21, Arnd Bergmann wrote:
> > > From: Arnd Bergmann
> > >
> > > Storing a bogus i2c_client structure on the stack adds ove
On 25/01/21, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Storing a bogus i2c_client structure on the stack adds overhead and
> causes a compile-time warning:
>
> drivers/tee/optee/rpc.c:493:6: error: stack frame size of 1056 bytes in
> function 'optee_handle_rpc' [-Werror,-Wframe-larger-than
On 26/01/21, Sai Prakash Ranjan wrote:
> As per register documentation, QCOM_WDT_ENABLE_IRQ which is BIT(1)
> of watchdog control register is wakeup interrupt enable bit and
> not related to bark interrupt at all, BIT(0) is used for that.
> So remove incorrect usage of this bit when supporting bark
On 09/09/19 03:21:16, Stephen Boyd wrote:
> Quoting Jorge Ramirez-Ortiz (2019-08-26 09:45:07)
> > @@ -76,10 +88,11 @@ static int qcom_apcs_msm8916_clk_probe(struct
> > platform_device *pdev)
> > a53cc->src_shift = 8;
> > a53cc->parent_map = gpll0_a
On 09/09/19 09:17:03, Stephen Boyd wrote:
> Quoting Jorge Ramirez-Ortiz, Linaro (2019-09-09 07:17:40)
> > On 09/09/19 03:21:16, Stephen Boyd wrote:
> > > Quoting Jorge Ramirez-Ortiz (2019-08-26 09:45:07)
> > > > @@ -76,10 +88,11 @@ static int qcom
On 10/09/19 11:06:55, Guenter Roeck wrote:
> On Fri, Sep 06, 2019 at 10:54:10PM +0200, Jorge Ramirez-Ortiz wrote:
> > Use the bark interrupt as the pre-timeout notifier whenever this
> > interrupt is available.
> >
> > By default, the pretimeout notification sha
On 01/06/20, Jorge Ramirez-Ortiz wrote:
> Some secure elements like NXP's SE050 sit on I2C buses. For OP-TEE to
> control this type of cryptographic devices it needs coordinated access
> to the bus, so collisions and RUNTIME_PM dont get in the way.
>
> This trampoline dr
On 08/06/20, Jens Wiklander wrote:
> On Mon, Jun 01, 2020 at 09:24:46AM +0200, Jorge Ramirez-Ortiz, Foundries
> wrote:
> > On 01/06/20, Sumit Garg wrote:
> > > Hi Jorge,
> >
> > hey
> >
> > >
> > > On Mon, 1 Jun 2020 at 04:41, Jorge
On 31/08/20, Randy Dunlap wrote:
> On 8/31/20 8:23 AM, Jorge Ramirez-Ortiz wrote:
> > When the optee driver is compiled into the kernel while the i2c core
> > is configured as a module, the i2c symbols are not available.
> >
> > This commit addresses the situation by di
On 13/08/20, Jens Wiklander wrote:
> On Wed, Aug 12, 2020 at 02:06:52PM +0200, Jorge Ramirez-Ortiz wrote:
> > Some secure elements like NXP's SE050 sit on I2C buses. For OP-TEE to
> > control this type of cryptographic devices it needs coordinated access
> > to
On 21/08/20, Jens Wiklander wrote:
> On Fri, Aug 14, 2020 at 01:12:21PM +0200, Jorge Ramirez-Ortiz wrote:
> > Some secure elements like NXP's SE050 sit on I2C buses. For OP-TEE to
> > control this type of cryptographic devices it needs coordinated access
> > to
On 24/07/20, Jorge Ramirez-Ortiz, Foundries wrote:
> On 24/07/20, Sumit Garg wrote:
> > On Thu, 23 Jul 2020 at 14:16, Jorge Ramirez-Ortiz
> > wrote:
> > >
> > > The current code waits for data to be available before attempting a
> > > second read. Howeve
On 22/07/20, Jorge Ramirez-Ortiz wrote:
> Some secure elements like NXP's SE050 sit on I2C buses. For OP-TEE to
> control this type of cryptographic devices it needs coordinated access
> to the bus, so collisions and RUNTIME_PM dont get in the way.
>
> This trampoline dr
On 24/07/20, Sumit Garg wrote:
> On Thu, 23 Jul 2020 at 14:16, Jorge Ramirez-Ortiz wrote:
> >
> > The current code waits for data to be available before attempting a
> > second read. However the second read would not be executed as the
> > while loop exits.
> >
On 22/09/20, Jens Wiklander wrote:
> On Wed, Sep 16, 2020 at 05:27:32PM +0200, Jorge Ramirez-Ortiz wrote:
> > Allow OP-TEE to specify the number of retries in the adaptor.
> >
> > Signed-off-by: Jorge Ramirez-Ortiz
> > ---
> > drivers/tee/optee/rpc.c |
On 23/09/20, Jorge Ramirez-Ortiz, Foundries wrote:
> On 22/09/20, Jens Wiklander wrote:
> > On Wed, Sep 16, 2020 at 05:27:32PM +0200, Jorge Ramirez-Ortiz wrote:
> > > Allow OP-TEE to specify the number of retries in the adaptor.
> > >
> > >
On 23/09/20, Jens Wiklander wrote:
> On Wed, Sep 23, 2020 at 01:26:31PM +0200, Jorge Ramirez-Ortiz, Foundries
> wrote:
> > On 23/09/20, Jorge Ramirez-Ortiz, Foundries wrote:
> > > On 22/09/20, Jens Wiklander wrote:
> > > > On Wed, Sep 16, 2020 at 05:27:32PM
401 - 437 of 437 matches
Mail list logo
