-
Notifications
You must be signed in to change notification settings - Fork 7.4k
net: change enc28j60 to new SPI API #662
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apply also the necessary changes pin-pointed by checkpatch (80chars limit etc...)
drivers/ethernet/eth_enc28j60.c
Outdated
@@ -43,12 +50,19 @@ static void eth_enc28j60_set_bank(struct device *dev, u16_t reg_addr) | |||
tx_buf[0] = ENC28J60_SPI_RCR | ENC28J60_REG_ECON1; | |||
tx_buf[1] = 0x0; | |||
|
|||
spi_transceive(context->spi, tx_buf, 2, tx_buf, 2); | |||
struct spi_buf tx_bufs[] = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Always declare variables at the beginning of a code block, not in the middle, so move this up.
Apply that rule everywhere.
e01c086
to
d4ba099
Compare
58d83a8
to
3ef1822
Compare
@tbursztyka the PR is updated to support legacy and new SPI interface now |
drivers/spi/Kconfig
Outdated
@@ -25,7 +25,7 @@ menuconfig SPI | |||
|
|||
config SPI_QMSI | |||
bool "QMSI driver for SPI controller" | |||
depends on SPI && QMSI | |||
depends on SPI && QMSI && SPI_LEGACY_API |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These Kconfig fixes should be in another patch
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what's platforms are exactly tested in the shippable builds for the enc28j60?
@@ -229,7 +231,7 @@ struct eth_enc28j60_runtime { | |||
CONFIG_ETH_ENC28J60_RX_THREAD_STACK_SIZE); | |||
struct k_thread thread; | |||
struct device *gpio; | |||
struct device *spi; | |||
struct spi_config spi_cfg; | |||
struct gpio_callback gpio_cb; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You will need #ifdef/#else/#endif instead of removing *spi
drivers/ethernet/eth_enc28j60.c
Outdated
config->gpio_pin); | ||
return -EINVAL; | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You don't need to configure the gpio cs by yourself, neither in spi legacy nor the new one.
drivers/ethernet/eth_enc28j60.c
Outdated
context->spi_cfg.vendor = 1; | ||
context->spi_cfg.cs = &enc_spi_cs; | ||
enc_spi_cs.gpio_pin = config->spi_cs_pin; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this will need no handle the case when config->spi_cs_port is just "" (aka: undefined), which means there is no need of enc_spi_cs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will do
5f04862
to
d3c3fc9
Compare
drivers/ethernet/eth_enc28j60.c
Outdated
return -EINVAL; | ||
} | ||
#endif | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[HOW COME github let me delete your comment, by mistake? how smart is this... sorry ]
spi_context_cs_configure() should do it, on spi driver side.
Could it be your board needs something specific? I see this GPIO_PUD_PULL_DOWN, looks like it's specific. (it's not supported by all gpio controller)
I could make a quick patch so extra gpio directives can be passed to gpio_pin_configure() in drivers/spi/spi_context.h
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no problem :-) , i might move that part into my board folder, thanks
4dd2cf5
to
e484ecb
Compare
@tbursztyka now everything should be addressed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's call it a go.
When legacy API will be finally dropped, it would be interesting to change the logic of writing/reading a packet in enc28j60's memory: trying to make it in one go, instead of looping currently by MAX_BUFFER_LENGTH (in "segments"). New spi api is exactly meant for this: avoiding multiple calls and memory copies.
Doing it right now would entangle way more #ifdefs everywhere so let's postpone this.
drivers/ethernet/eth_enc28j60.c
Outdated
.gpio_pin = 0, | ||
.delay = 0 | ||
}; | ||
#endif |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if we are moving this driver to new API, why are we checking for legacy?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The patch makes both SPI API supported, choice being made at built time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nashif the driver tests are still using platforms not supporting the new SPI interface, at the moment supporting both API's gives us a higher test coverage
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The patch makes both SPI API supported, choice being made at built time.
we should only support one API, and if a platform still support the old API, it will never be moved if we keep this running in this mode and we will end up with 2 APIs for a long time.
I prefer to have this support 1 single API and accelerate the move to the new API with a deadline.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nashif no problem, I agree with that, but there is still the open question, how to handle the tests then?
Signed-off-by: Matthias Boesl <[email protected]>
Signed-off-by: Matthias Boesl <[email protected]>
superseeded by #5921 |
Signed-off-by: Matthias Boesl [email protected]