Introduce qspi_inst_t type for QSPI instructions #11604

kyle-cypress · 2019-10-01T00:12:14Z

Description

Encourage the usage of consistent types (there are currently a mix of int and unsigned int used for qspi instructions)
QSPI commands are limited to 8 bits, to this is a typdef to uint8_t

Pull request type

[ ] Fix
[x] Refactor
[ ] Target update
[ ] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

Reviewers

Release Notes

kyle-cypress · 2019-10-01T00:16:28Z

Split from #11531 , see discussion at #11531 (comment)

ciarmcom · 2019-10-01T01:00:27Z

@kyle-cypress, thank you for your changes.
@ARMmbed/mbed-os-storage @ARMmbed/mbed-os-core @ARMmbed/mbed-os-maintainers please review.

0xc0170 · 2019-10-01T10:21:49Z

drivers/QSPI.h

@@ -39,6 +41,10 @@ namespace mbed {
 * @{
 */

+/** Type representing a QSPI instruction
+ */
+typedef uint8_t qspi_inst_t;


qspi_status_t in the HAL defines the instruction as uint8_t. However, the drivers use "fundamental types", see other drivers like SPI. See https://os.mbed.com/handbook/C-Data-Types for details.
Although we use C99 types in HAL.

For consistency, I would leave this as it is or at least go with "unsigned char". We could challenge using these fundamental types in drivers, I recall we were asked previously. Like this one: https://os.mbed.com/questions/1749/What-are-the-preferred-data-types-for-mb/

We should fix the storage if they use unsigned for whatever reason to use the same one.

Updated the typdef to use char instead.

bulislaw

Looks good and shouldn't break source backward compatibility.

VeijoPesonen · 2019-10-03T07:04:03Z

drivers/source/QSPI.cpp

 {
    memset(&_qspi_command, 0,  sizeof(qspi_command_t));
    //Set up instruction phase parameters
    _qspi_command.instruction.bus_width = _inst_width;
-    if (instruction != -1) {
+    if (instruction != QSPI_NO_INST) {


Switch from -1 to 0 was intentional? Is there some other PR which is related to this change?

Since qspi_inst_t is now an unsigned char, -1 is not a valid value. The #define is additionally introduced to improve clarity.
This did however prompt me to check and I noticed that there were two locations where -1 was still being passed to _qspi_build_command; I've pushed up a change updating those to use QSPI_NO_INST.

VeijoPesonen

Looks good to me.

maclobdell · 2019-10-08T19:14:31Z

@ARMmbed/mbed-os-maintainers - it looks like @0xc0170's requests have been addressed. Can this be merged? @ARMmbed/mbed-os-core - can you review and approve?

0xc0170 · 2019-10-14T07:33:50Z

CI started

mbed-ci · 2019-10-14T08:24:14Z

Test run: FAILED

Summary: 3 of 4 test jobs failed
Build number : 1
Build artifacts

Failed test jobs:

jenkins-ci/mbed-os-ci_build-ARM
jenkins-ci/mbed-os-ci_build-IAR
jenkins-ci/mbed-os-ci_build-GCC_ARM

0xc0170 · 2019-10-14T08:49:34Z

I fixed the build failure directly on your branch, restarting CI

0xc0170 · 2019-10-14T08:50:10Z

Before I start internal tests, I'll wait for Travis, this might need a rebase, will try to do it :)

0xc0170 · 2019-10-14T09:13:39Z

Looks like travis passed (little fs only ongoing), starting CI

mbed-ci · 2019-10-14T09:52:33Z

Test run: FAILED

Summary: 3 of 4 test jobs failed
Build number : 3
Build artifacts

Failed test jobs:

jenkins-ci/mbed-os-ci_build-ARM
jenkins-ci/mbed-os-ci_build-IAR
jenkins-ci/mbed-os-ci_build-GCC_ARM

adbridge · 2019-10-14T09:55:38Z

Looks like there are genuine, related CI failures on this PR. @kyle-cypress please investigate

mbed-ci · 2019-10-15T10:50:40Z

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 4
Build artifacts

0xc0170 · 2019-10-15T12:54:39Z

drivers/QSPI.h

@@ -28,6 +28,8 @@

 #define ONE_MHZ     1000000

+#define QSPI_NO_INST 0x00


One additional request, please send new PR: Is this documented anywhere? There are in doxygen notes about: "use this value for this phase to be ignored" . This would be good to have there as well otherwise this define is not known to a user.

Submitted #11691

0xc0170 · 2019-10-15T12:56:46Z

What about the code that used previously -1 for skiping the instruction phase? If they fetch this update, it will be translated to a huge value (won't work), won't it? Shall this be considered breaking change?

Refactor

I would challenge this one to be functionality change rather or even breaking change.

kyle-cypress · 2019-10-15T23:28:13Z

What about the code that used previously -1 for skiping the instruction phase? If they fetch this update, it will be translated to a huge value (won't work), won't it? Shall this be considered breaking change?

Refactor

I would challenge this one to be functionality change rather or even breaking change.

Pushed 021ecd0 to change the typedef's underlying type to int instead of char. That way we get the benefits of consistency and clarity from retaining the typedef, but without the backwards compatibility concern.

Encourage the usage of consistent types (there are currently a mix of `int` and `unsigned int` used for qspi instructions) QSPI commands are limited to 8 bits, to this is a typdef to char

Existing code may a dependency on the old behavior of "-1" to mean "no instruction". Therefore, update the typedef, and the value of QSPI_NO_INST, to avoid breaking those uses.

kyle-cypress · 2019-10-16T22:57:29Z

Rebased on latest master to enable rebasing #11531 on this (to test with the changes to qspi_inst_t and QSPI_NO_INST).

0xc0170 · 2019-10-17T07:21:21Z

CI started

So this will need one more rebase ?

mbed-ci · 2019-10-17T10:01:47Z

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 5
Build artifacts

0xc0170 · 2019-10-17T13:05:22Z

So this will need one more rebase ?

Set as needs: review , otherwise it looks ready

jeromecoutant · 2019-10-17T13:28:18Z

Hi
Tested OK with DISCO_L475VG_IOT01A-ARMC6

kyle-cypress · 2019-10-17T15:24:54Z

So this will need one more rebase ?

Set as needs: review , otherwise it looks ready

No, no further rebase is required. The rebase I pushed yesterday is off of master; the comment about #11531 was simply to provide context for the force-push (since there were no merge conflicts that would have prompted a rebase).

kyle-cypress mentioned this pull request Oct 1, 2019

Improve QSPIFBlockDevice conformance to SFDP #11531

Merged

ciarmcom requested review from a team October 1, 2019 01:00

ciarmcom added the needs: review label Oct 1, 2019

0xc0170 requested changes Oct 1, 2019

View reviewed changes

0xc0170 added needs: work and removed needs: review labels Oct 1, 2019

kyle-cypress force-pushed the pr/qspi-inst-type branch from 1a1819b to bcd98ab Compare October 1, 2019 15:14

bulislaw approved these changes Oct 1, 2019

View reviewed changes

SeppoTakalo approved these changes Oct 2, 2019

View reviewed changes

VeijoPesonen reviewed Oct 3, 2019

View reviewed changes

kyle-cypress force-pushed the pr/qspi-inst-type branch from bcd98ab to 6ae6a82 Compare October 3, 2019 14:58

VeijoPesonen approved these changes Oct 4, 2019

View reviewed changes

adbridge added needs: CI release-version: 5.14.1 and removed needs: work labels Oct 11, 2019

0xc0170 self-requested a review October 14, 2019 07:32

0xc0170 approved these changes Oct 14, 2019

View reviewed changes

adbridge removed the needs: CI label Oct 14, 2019

0xc0170 added the needs: CI label Oct 15, 2019

0xc0170 added ready for merge and removed needs: CI labels Oct 15, 2019

0xc0170 reviewed Oct 15, 2019

View reviewed changes

0xc0170 added needs: review and removed ready for merge labels Oct 15, 2019

kyle-cypress mentioned this pull request Oct 15, 2019

QSPI: document use of QSPI_NO_INST #11691

Merged

0xc0170 approved these changes Oct 16, 2019

View reviewed changes

0xc0170 added needs: CI and removed needs: review labels Oct 16, 2019

Matthew Macovsky and others added 4 commits October 16, 2019 15:31

Introduce qspi_inst_t type for QSPI instructions

b1916fc

Encourage the usage of consistent types (there are currently a mix of `int` and `unsigned int` used for qspi instructions) QSPI commands are limited to 8 bits, to this is a typdef to char

QSPIFBlockDevice: fix type on the namespace mbed

fa6e01a

QSPIFBlockDevice: Fix incomplete propagation of qspi_inst_t

52332f9

Change qspi_inst_t typdef to int

555140a

Existing code may a dependency on the old behavior of "-1" to mean "no instruction". Therefore, update the typedef, and the value of QSPI_NO_INST, to avoid breaking those uses.

kyle-cypress force-pushed the pr/qspi-inst-type branch from 021ecd0 to 555140a Compare October 16, 2019 22:56

0xc0170 added needs: review and removed needs: CI labels Oct 17, 2019

0xc0170 added ready for merge and removed needs: review labels Oct 18, 2019

0xc0170 merged commit b6266b5 into ARMmbed:master Oct 18, 2019

0xc0170 removed the ready for merge label Oct 18, 2019

		@@ -28,6 +28,8 @@

		#define ONE_MHZ 1000000

		#define QSPI_NO_INST 0x00

Introduce qspi_inst_t type for QSPI instructions #11604

Introduce qspi_inst_t type for QSPI instructions #11604

Uh oh!

Conversation

kyle-cypress commented Oct 1, 2019

Description

Pull request type

Reviewers

Release Notes

Uh oh!

kyle-cypress commented Oct 1, 2019

Uh oh!

ciarmcom commented Oct 1, 2019

Uh oh!

0xc0170 Oct 1, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bulislaw left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

VeijoPesonen left a comment

Choose a reason for hiding this comment

Uh oh!

maclobdell commented Oct 8, 2019

Uh oh!

0xc0170 commented Oct 14, 2019

Uh oh!

mbed-ci commented Oct 14, 2019

Uh oh!

0xc0170 commented Oct 14, 2019

Uh oh!

0xc0170 commented Oct 14, 2019

Uh oh!

0xc0170 commented Oct 14, 2019

Uh oh!

mbed-ci commented Oct 14, 2019

Uh oh!

adbridge commented Oct 14, 2019

Uh oh!

mbed-ci commented Oct 15, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

0xc0170 commented Oct 15, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kyle-cypress commented Oct 15, 2019

Uh oh!

kyle-cypress commented Oct 16, 2019

Uh oh!

0xc0170 commented Oct 17, 2019

Uh oh!

mbed-ci commented Oct 17, 2019

Uh oh!

0xc0170 commented Oct 17, 2019

Uh oh!

jeromecoutant commented Oct 17, 2019

Uh oh!

kyle-cypress commented Oct 17, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

0xc0170 Oct 1, 2019 •

edited

Loading

0xc0170 commented Oct 15, 2019 •

edited

Loading

kyle-cypress commented Oct 17, 2019 •

edited

Loading