Differential D42318
Support for rockchip serial flash controller Authored by titus_edc.ro on Oct 20 2023, 7:24 PM. Tags None Referenced Files
Subscribers
Details Its mostly a clone of the linux driver excluding dma support. I added to flash devices to sys/dev/flash/mx25l.c (the ones i have on my boards) i tested with dd in and out and it made an identical copy (not the first time :))
Diff Detail
Event TimelineComment Actions If "[i]ts mostly a clone of the linux driver" means copying of GPL licensed source code, FreeBSD avoids adding GPL licensed source code, so that the resultant source code in FreeBSD is not GPL licensed. Relicensing GPL source code to enable its addition into FreeBSD needs to be explicit with the original owners of the original source code license(s)/copyrights. From the wording I cannot tell if there is a licensing issue here or not. Comment Actions Agreed, I do not really understand too if it's "copied from Linux" or "Took Linux code as an inspiration". Comment Actions I'll take a look... but the concept of being tainted merely by reading gpl code has no basis in law and is utter BS and a scare campaign by some. It didn't work with AT&T who had actual contracts in place and there is no legal theory that's ever been successfully put forward that comes anywhere close.... However, given the FUD in this area, I don't blame anybody for erring on the side of caution. Comment Actions I've taken a look at spi-rockport-sfc.c and compared it to what's under review. I've not looked at every single line, only a sample at the present time. I've eyeballed the rations below. This is not a verbatim copy. So with the verbatim comments and printf statements fixed; the repeated code turned into macros; and possibly some rewriting here and there, the risk would be low. The current submission is a mix of heavily inspired and thinly rewritten code with a fair amount of completely original code. My recommendation would be for me to go through this and make specific recommendations to change, have the author change them and see where we wind up. There's a number of other drivers in this, and other BSDs, that lift the core bits of talking to the hardware differ this much or less from the linux drivers. With some changes, I believe that the differences between this and the linux driver will be safely on the 'transformative changes such that it creates a new work' side of the blurry line. Without these changes, I'd be hesitant to commit the driver. Comments? Comment Actions I checked the RK3328 TRM, and the register names appear to match (there are several that are the same, but I didn't check them all). Comment Actions I know that being tainted by reading GPL is mostly BS but for "small" drivers like that it's easy to read the Linux code and just copy it by "accident", I real GPL code without problems but I usually do it when I'm having problems implementing a driver (usually because datasheet is incomplete or wrong). Comment Actions Good news ;)
Yeah writing to registers for an operation will always be the same.
Likely not a problem.
Of course.
Obvisously.
Ok, thanks for this.
That sounds good for me.
Comment Actions So, it looks like the Linux driver used its own names, not the names that are in the TRM (at least not the ones in the RK3568 that I found). I know it's a pain. Using the names from the TRM makes this 'just using the interface names, as defined by the spec' which is not copywriteable. So I'd use the correct names to create a sed script. I'd also do s/SFC_/FSPI_/ in the register names and bit/field names since the registers are named FSPI in the TRM. That's enough for the first round of changes. I'll write more for places that common code can be reduced to a macro/inline function.
Comment Actions I've looked at the PX30 TRM and the registers are named like in this code.
Comment Actions If the PX30 uses these names, then ignore my name change request. I could only find the datasheetcwhich lacks the register info. I'll do round 2 tomorrow. Comment Actions fixed register names, bit names after rk3568 trn manual there is a problem with the maximum transfer size which for gen 3 is rather small (15K) the easiest way would probably be to add a function to spibus_if which default to returning 0 (no maximum transfer size) and override it in rk_fspi and then use it in mx25l.c to advertise it to upper layer Comment Actions Needs the copyright. My first pass is that this is different enough to not pose problems.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||