Dear Alexandre Pereira da Silva,
> Some boards and card slots doesn't have card detect feature available.
> In that case allow to mark the cards as non-removable, via devicetree.
>
> Signed-off-by: Alexandre Pereira da Silva
Looks good,
Reviewed-by: Marek Vasut
btw. did you
mx23 olinuxino seems perfectly removable to me ... on all possible
models and even prototypes and hybrids too ;-)
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ly well on this board, so I don't get it.
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Dear Mark Brown,
> On Fri, Apr 05, 2013 at 08:37:39AM +0200, Marek Vasut wrote:
> > btw. did you know you can let git send-email automatically handle CC for
> > you so you don't have to type it into the command line by simply
> > sticking
> >
> > Cc:
Dear Alexandre Pereira da Silva,
> On Fri, Apr 5, 2013 at 11:11 AM, Marek Vasut wrote:
> > The CD line is working perfectly well on this board, so I don't get it.
>
> In the schematics of this board, the SSP1_DETECT pin is connected to
> the green led. As I see, there
("mmc: spi: Pull out parts shared between MMC and SPI") from
> the spi-mb tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
On a quick glance, it seems correct. Thank you!
Best regards,
Marek Vasut
--
To unsubscribe from this lis
palmz72_defconfig results in:
>
> /home/arnd/linux-arm/arch/arm/mach-pxa/palmte2.c:128:31: warning:
> 'palmte2_pxa_keys' defined but not used [-Wunused-variable]
>
> Signed-off-by: Arnd Bergmann
> Cc: Marek Vasut
> Cc: Carlos Eduardo Medaglia Dyonisio
> Cc: Hao
Dear Jingoo Han,
> Add 'const' to static array that was missing it in its
> definition.
Did you get compiler warning? Still, this is a good pick
Acked-by: Marek Vasut
> Signed-off-by: Jingoo Han
> Cc: Marek Vasut
> Cc: Richard Purdie
> ---
[...]
Best regards,
M
llowing standards (ONFI). Is this an obstacle to
> >> merging?
> >
> > No. I already pushed it.
>
> This is a "bump" for a 3.7-rc pull request. This regression has been
> noticed by others.
[whine] my nand doesn't work ;-)
Thanks for keeping e
ke that is already in -next:
mmc: mxs-mmc: Let device core handle pinctrl
Otherwise
Tested-by: Marek Vasut
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
lso propose to convert the 50MHZ flag to OF as well.
>
> Other option is to handle this the same way as the 50MHZ flag, that is
> being set by board code.
I wouldn't mind, but we should use something generic the other PHYs can use as
well.
Best regards,
Marek Vasut
--
To unsubscr
egulator;
> + return PTR_ERR(rdev);
> }
>
> /* Save regulator for cleanup */
> @@ -1021,7 +1021,7 @@ static int palmas_regulators_probe(struct
> platform_device *pdev) id, reg_init);
> if (ret) {
>
t;
> static struct platform_driver rc5t583_regulator_driver = {
> @@ -208,7 +191,6 @@ static struct platform_driver rc5t583_regulator_driver
> = { .owner= THIS_MODULE,
> },
> .probe = rc5t583_regulator_probe,
> - .remove = rc5t583_regulator_remove,
> };
>
&
Dear Sachin Kamat,
> devm_* simplifies the code.
>
> Signed-off-by: Sachin Kamat
Makes sense
Acked-by: Marek Vasut
> ---
> This series is compile tested.
> ---
> drivers/regulator/anatop-regulator.c |3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
&
Dear Sachin Kamat,
> devm_* simplifies the code.
>
> Signed-off-by: Sachin Kamat
Acked-by: Marek Vasut
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majo
Dear Sachin Kamat,
> devm_* simplifies the code.
>
> Signed-off-by: Sachin Kamat
Acked-by: Marek Vasut
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majo
Dear Sachin Kamat,
> devm_* simplifies the code.
>
> Signed-off-by: Sachin Kamat
Acked-by: Marek Vasut
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majo
orts won't get lost in a deferred probe.
>
> Signed-off-by: Wolfram Sang
> Cc: Marek Vasut
Certainly makes sense,
Acked-by: Marek Vasut
Thanks!
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messa
uot;HID: add quirk for Freescale i.MX28 ROM recovery") from
> the hid tree.
>
> Just context changes. I fixed it up (see below) and can carry the fix as
> necessary (no action is required).
Looks obviously correct, thank you Stephen!
Best regards,
Marek Vasut
--
To unsubscribe
Dear David Woodhouse,
> On Tue, 2012-10-09 at 23:39 -0700, Brian Norris wrote:
> > I can see if that's possible, but I think it's unlikely. They don't
> > even bother following standards (ONFI). Is this an obstacle to
> > merging?
>
> No. I already pus
Dear Jingoo Han,
> By using devm_gpio_request_one it is possible to set the direction
> and initial value in one shot. Thus, using devm_gpio_request_one
> can make the code simpler.
>
> Signed-off-by: Jingoo Han
> Cc: Richard Purdie
> Cc: Marek Vasut
Acked-by: Marek Vas
ters
between
each segment of the DMA chain (just as MXS SPI does it)
3) You might run out of DMA descriptors when doing too long chains -- so you
might need to fix that part of the mxs DMA driver.
> thanks
> Huang Shijie
Best regards,
Marek Vasut
--
To unsubscribe from this list: send t
Dear Huang Shijie,
> 于 2012年10月18日 15:14, Marek Vasut 写道:
> > Dear Huang Shijie,
> >
> > Why such massive CC ?
> >
> >> 于 2012年10月18日 14:18, Vinod Koul 写道:
> >>> Why cant you do start (prepare clock etc) when you submit the
> >>>
Dear Huang Shijie,
> 于 2012年10月18日 16:16, Marek Vasut 写道:
> > So we can't stream data from the chip? About time to adjust the MTD
> > framework to allow that. Maybe implement a command queue?
>
> IMHO, it's not possible. Because the READ-PAGE(00h-30h) command n
Dear Huang Shijie,
> 于 2012年10月18日 16:49, Marek Vasut 写道:
> > Dear Huang Shijie,
> >
> >> 于 2012年10月18日 16:16, Marek Vasut 写道:
> >>> So we can't stream data from the chip? About time to adjust the MTD
> >>> framework to allow that. Maybe
around 30us.
> So we just increase the clock freqeuncy driving the timers
> here.
Thanks for the set. Just a really quick question -- won't this under no
circumstance cause interrupt storm?
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linu
Dear Jean Delvare,
> With the recent code cleanup from Marek Vasut, driver gpio-ucb1400 can
> be built as a module, so change symbol GPIO_UCB1400 from bool to
> tristate.
>
> Signed-off-by: Jean Delvare
> Cc: Marek Vasut
> Cc: Grant Likely
> Cc: Linus Walleij
width = <18>;
But it's also true we have all 24 data lines routed to the LCD.
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
tant part of the color definition.
>
> So, to fix the colors display, just get back to the default controller
> behaviour.
>
> Signed-off-by: Maxime Ripard
Did you receive my latest email? Check M28EVK (imx28-m28evk.dts), it uses 18bit
LCD and works without this patch I think.
Dear Maxime Ripard,
> Hi Marek,
>
> Le 22/04/2013 11:16, Marek Vasut a écrit :
> > Dear Maxime Ripard,
> >
> >> The current code always registers as a 32 bits display, and uses the
> >> hardware to drop the MSB of each color to abjust to the
ny trick that allows bi-directional communication.
It can't do full duplex. I tested it with master-slave communication (half-
duplex) and various SPI flashes.
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mes
rrupt for the keypad controller
> +- marvell,debounce-interval : How long time the key will be
Is there no generic prop name for this debounce interval?
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
ound !?
Only one question comes to mind with this email -- what do LRADC and I2C have
to
do with each other here ?
It'd be nice if someone could summarize on what I should focus and possibly
prepare a testcase.
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
c8 0013
> [ 936.449389] [] (__irq_svc+0x44/0x54) from []
> (cpu_arm926_switch_mm+0x8/0x20)
> [ 936.458217] [] (cpu_arm926_switch_mm+0x8/0x20) from
> [] (0xc6e303c0)
>
> The system does not completely die but it is extremely slow and almost
> unusable, I checked tha
iio->trig , you dont want to do that in case of failure
> - return 0;
> + return ret;
> }
>
> static void mxs_lradc_trigger_remove(struct iio_dev *iio)
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Dear Otavio Salvador,
> On Mon, Jul 15, 2013 at 11:24 AM, Marek Vasut wrote:
> > Dear Otavio Salvador,
> >
> >> As we have a 'ret' variable with the iio_trigger_register return, this
> >> can be used as result.
> >>
> >> Signed-off-
), instead of between 0 and 0xfff (12 bits).
>
> Signed-off-by: Hector Palacios
Acked-by: Marek Vasut
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
t;, "fsl,imx23-lradc"
This is a separate fix, but I think it's not that important to rework the whole
patchset because of it.
Acked-by: Marek Vasut
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messag
turn IIO_VAL_INT_PLUS_NANO;
> +}
> +
> static ssize_t mxs_lradc_show_scale_available_ch(struct device *dev,
> struct device_attribute *attr,
> char *buf,
> @@ -400,6 +451,8 @@ static const struct attribute_group
> mxs_lradc_attribute_group = { static const st
.scan_type = { \
> .sign = 'u', \
> @@ -960,6 +977,12 @@ static int mxs_lradc_probe(struct platform_device
> *pdev) goto err_addr;
> }
>
> + /* Grab Vref array from DT
Dear Hector Palacios,
> Dear Marek,
>
> On 07/19/2013 04:39 PM, Marek Vasut wrote:
> > Dear Hector Palacios,
> >
> >> Added write_raw function to manipulate the optional divider_by_two
> >> through the scaling attribute out of the available scales.
&g
Dear Hector Palacios,
> Dear Marek,
>
> On 07/19/2013 04:30 PM, Marek Vasut wrote:
> >> @@ -228,39 +230,12 @@ struct mxs_lradc {
> >>
> >> #define LRADC_RESOLUTION 12
> >> #define LRADC_SINGLE_SAMPLE_MASK ((1 << LRA
Dear Jonathan Cameron,
> On 07/19/2013 05:22 PM, Hector Palacios wrote:
> > Dear Marek,
> >
> > On 07/19/2013 06:17 PM, Marek Vasut wrote:
> >>> Here you have three entries per channel:
> >>> in_voltageX_raw-> the sample raw value
> &g
Dear Hector Palacios,
> Hi Marek,
>
> On 07/19/2013 06:14 PM, Marek Vasut wrote:
> > Dear Hector Palacios,
> >
> >> Dear Marek,
> >>
> >> On 07/19/2013 04:30 PM, Marek Vasut wrote:
> >>>> @@ -228,39 +230,12 @
Hi Hector,
> Hi Marek,
>
> On 07/22/2013 09:42 AM, Marek Vasut wrote:
> > Dear Hector Palacios,
> >
> >> Hi Marek,
> >>
> >> On 07/19/2013 06:14 PM, Marek Vasut wrote:
> >>> Dear Hector Palacios,
> >>>
>
Dear Hector Palacios,
> Added write_raw function to manipulate the optional divider_by_two
> through the scaling attribute out of the available scales.
>
> Signed-off-by: Hector Palacios
> ---
Yep, looks nicer,
Reviewed-by: Marek Vasut
Best regards,
Marek Vasut
--
To unsubs
vail[i][s].nano =
> + do_div(scale_uv, 1) * 10;
Are we not loosing precission here?
> + lradc->scale_avail[i][s].integer = scale_uv;
> + }
> + }
> +
> /* Configure the hardware. */
> mxs_lradc_h
/msg36691.ht
> ml I guess I'm not alone with that opinion.
>
> - Lars
He's talking about different versions of the IP block, this is the same IP
block, just connected to different inputs.
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe
rd kernels. This series adds a flag
> to the chip specific data to solve this. Also some unnecessary ifdefs
> are removed.
>
> Sascha
Went through the whole series,
Acked-by: Marek Vasut
Thanks!
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscrib
at25c17", CAT25_INFO( 256, 8, 32, 2, M25P_NO_ERASE) },
> + { "cat25128", CAT25_INFO(2048, 8, 64, 2, M25P_NO_ERASE) },
> { },
> };
> MODULE_DEVICE_TABLE(spi, m25p_ids);
I can't say I like the growing macro magic (voodoo?) in this file, but your
patch doe
lling must be
> > > used. - non-removable: non-removable slot (like eMMC); assume always
> > > present.
> >
> > But mxs-mmc set MMC_CAP_NEEDS_POLL unconditionally.
>
> I will work on a better way to fix this.
NEEDS_POLL looks nice and seems to fit this ca
onfigured CD line and they may break.
>
> Ah, yes. I thought that any board that has CD support has to reference
> 'mmc0_cd_cfg'. That's not necessarily true.
>
> > The driver will call get_cd() upon probing, which returns the status of
> > the CD line. Please che
Dear Hector Palacios,
> Dear Marek Vasut,
>
> On 04/08/2013 06:28 PM, Marek Vasut wrote:
> > Dear Shawn Guo,
> >
> >> On Mon, Apr 08, 2013 at 03:58:05PM +0200, Hector Palacios wrote:
> >>> On 04/08/2013 02:48 PM, Shawn Guo wrote:
> >>>>
Hi Hector,
> Dear Marek Vasut,
>
> On 04/09/2013 10:15 AM, Marek Vasut wrote:
> > Dear Hector Palacios,
> >
> >> Dear Marek Vasut,
> >>
> >> On 04/08/2013 06:28 PM, Marek Vasut wrote:
> >>> Dear Shawn Guo,
> >>>
Cc: Linus Walleij
Cc: Jean Delvare
Cc: Samuel Ortiz
Cc: Mark Brown
Cc: Guenter Roeck
Cc: linux-kernel
Cc: Grant Likely
Signed-off-by: Marek Vasut
---
drivers/gpio/gpio-ucb1400.c | 19 ++-
drivers/mfd/ucb1400_core.c |5 +
include/linux/ucb1400.h | 18
Dear Marek Vasut,
> Cc: Linus Walleij
> Cc: Jean Delvare
> Cc: Samuel Ortiz
> Cc: Mark Brown
> Cc: Guenter Roeck
> Cc: linux-kernel
> Cc: Grant Likely
> Signed-off-by: Marek Vasut
> ---
> drivers/gpio/gpio-ucb1400.c | 19 ++-
> d
ing on that?
>
> I am not aware of the latest status about chipidea usb otg support for
> i.mx.
I gave up on tracking that mayhem.
> Please post this question in the linux-usb list and add Peter Chen, the
> folks from Pengutronix and Alexander Shishkin in Cc.
Good idea. Also pl
ooked something, please let me know.
>
> Interestingly, the author made an attempt to fix that with [1]. It looks
> like the rest of that series was merged, but this patch wasn't, though I
> don't find any information about the reason.
It's been a while. Guenter, than
Dear Guenter Roeck,
> On Sat, Mar 30, 2013 at 08:20:44PM +0100, Marek Vasut wrote:
> > Dear Guenter Roeck,
> >
> > > On Fri, Mar 29, 2013 at 08:46:39PM +0100, Jean Delvare wrote:
> > > > Hi all,
> > > >
> > > > In September 2009, a
have any board with this one, yet I think this change is correct, so:
Reviewed-by: Marek Vasut
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://
was tested (and developed) on this board:
http://www.denx-cs.de/?q=M28
The userland code is really easy too, simply pump it into spidev or read from
it. But all that is only possible because of the SPI IP in the mx28 is nice.
> Regards,
>
> Fabio Estevam
Best regards,
Marek Vasut
coming days :)
Good luck with that.
> Thanks to all of you who provided suggestions.
> Carlo Bastelli
>
> - Original Message -
> From: "Ned Forrester"
> To: "Marek Vasut"
> Cc: "Fabio Estevam" ;
> ; "Bastelli Carlo (yahoo)"
Dear Peter Senna Tschudin,
> From: Peter Senna Tschudin
The patch description is a bit crap, but otherwise
Acked-by: Marek Vasut
> Convert a nonnegative error return code to a negative one, as returned
> elsewhere in the function.
>
> A simplified version of the semantic m
Dear Tomas Hlavacek,
> Support for read/modify of uartclk via sysfs added.
> It may prove useful with some no-name cards that
> has different oscillator speeds and no distinguishing
> PCI IDs to allow autodetection. It allows better integration
> with udev and/or init scripts.
>
> Signed-off-by:
emoves
> > CONFIG_MTD_NAND_VERIFY_WRITE from all defconfig files.
>
> thanks a lot.
>
> I will send out a separate patch to fix it.
I'd still prefer for this to be rather fixed. It seems to be able to find some
obvious mistakes etc.
[...]
Best regards,
Marek Vasut
--
To u
Dear Huang Shijie,
> 于 2012年08月15日 20:09, Marek Vasut 写道:
> > I'd still prefer for this to be rather fixed. It seems to be able to find
> > some obvious mistakes etc.
>
> could you please point out the mistakes?
Usual stuff -- flaws in drivers, misbehavior of the chi
e device initialization
> > on it's own.
>
> No, not at all.
>
> > And I should add add the attribute (via struct attribute_group) to
> > struct device in between device_initialize() and device_add() calls.
> > Did I get it right?
>
> No, make th
Dear Shawn Guo,
> On 17 August 2012 10:57, Marek Vasut wrote:
> > Thanks ... still, is there some key for those tags? Or do you invent them
> > at random and then let people guess what's right? Some git grep on
> > Documentation directory gets me nothing.
>
> T
ing at the log for what you are patching will do
> the job? (I can't immediately spot anything equivalent in there...)
That might just be it ;-)
Thanks
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
avoid the error.
>
> Also define 'DA9052_IRQF' for improving readability.
>
> Signed-off-by: Fabio Estevam
Reviewed-by: Marek Vasut
> ---
> drivers/mfd/da9052-core.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a
0644
> --- a/drivers/mtd/spi-nor/Kconfig
> +++ b/drivers/mtd/spi-nor/Kconfig
> @@ -40,7 +40,7 @@ config SPI_ATMEL_QUADSPI
>
> config SPI_CADENCE_QUADSPI
> tristate "Cadence Quad SPI controller"
> - depends on OF && (ARM || COMPILE_TEST)
> + depends on OF && ARM
> help
> Enable support for the Cadence Quad SPI Flash controller.
>
>
--
Best regards,
Marek Vasut
On 07/20/2016 04:50 AM, Brian Norris wrote:
> On Wed, Jul 20, 2016 at 03:50:27AM +0200, Marek Vasut wrote:
>> On 07/19/2016 10:05 PM, Brian Norris wrote:
>>> On Tue, Jul 19, 2016 at 08:03:00AM +0200, Stefan Roese wrote:
>>>> On 18.07.2016 22:20, Brian Norris wrote:
On 07/20/2016 05:25 AM, Brian Norris wrote:
> On Wed, Jul 20, 2016 at 04:58:08AM +0200, Marek Vasut wrote:
>> On 07/20/2016 04:50 AM, Brian Norris wrote:
>>> On Wed, Jul 20, 2016 at 03:50:27AM +0200, Marek Vasut wrote:
>>>> On 07/19/2016 10:05 PM, Brian Norris wrote:
Add new binding to enable loop-back
>> circuit
>> mtd: spi-nor: cadence-quadspi: Add support to enable loop-back clock
>> circuit
>> mtd: spi-nor: cadence-quadspi: Fix error path in probe
>> mtd: spi-nor: cadence-quadspi: Add runtime PM support
>>
>>
d 'disable-over-current' binding to allow of the
> option of disabling the over-current condition.
>
> Signed-off-by: Dinh Nguyen
Reviewed-by: Marek Vasut
Similar patch was in U-Boot for two years now and it does the trick indeed.
> ---
> drivers/usb/dwc2/core.h |
On 10/17/2017 12:29 AM, Cyrille Pitchen wrote:
> Hi all,
>
> Le 16/10/2017 à 11:28, Marek Vasut a écrit :
>> On 10/16/2017 08:15 AM, Vignesh R wrote:
>>>
>>>
>>> On Tuesday 03 October 2017 10:49 AM, Vignesh R wrote:
>>>>
>>>>
On 05/28/2017 08:02 AM, Axel Lin wrote:
> These functions are only used by this driver, make them static.
>
> Signed-off-by: Axel Lin
Obviously correct,
Acked-by: Marek Vasut
> ---
> drivers/regulator/bd9571mwv-regulator.c | 12 ++--
> 1 file changed, 6 insertio
g)&bxt_info },
> + { PCI_VDEVICE(INTEL, 0xa1a4), (unsigned long)&bxt_info },
> + { PCI_VDEVICE(INTEL, 0xa224), (unsigned long)&bxt_info },
> { },
> };
> MODULE_DEVICE_TABLE(pci, intel_spi_pci_ids);
>
--
Best regards,
Marek Vasut
On 10/29/2017 11:16 AM, Mika Westerberg wrote:
> On Sun, Oct 29, 2017 at 11:09:50AM +0100, Marek Vasut wrote:
>> On 10/29/2017 10:57 AM, sathyanarayanan.kuppusw...@linux.intel.com wrote:
>>> From: Kuppuswamy Sathyanarayanan
>>>
>>>
>>> This patch ad
On 10/06/2015 16:22, Alexandre Belloni wrote:
0° Kelvin is actually −273.15°C, not -272.15°C. Fix the temperature offset.
Reported-by: Janusz Użycki
Signed-off-by: Alexandre Belloni
Nice find :-)
Acked-by: Marek Vasut
(I am using different MUA, please pardon the possible issues
On 10/06/2015 20:43, Stefan Wahren wrote:
Hi,
Alexandre Belloni hat am 6. Oktober
2015 um 16:22 geschrieben:
0° Kelvin is actually −273.15°C, not -272.15°C. Fix the temperature offset.
Reported-by: Janusz Użycki
Signed-off-by: Alexandre Belloni
---
drivers/staging/iio/adc/mxs-lradc.c | 6
s have it.
>
> Signed-off-by: Arnd Bergmann
> Fixes: a2712e6c75f ("crypto: mxs-dcp - Allow MXS_DCP to be used on MX6SL")
Acked-by: Marek Vasut
> diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
> index ab7e3b668890..2569e043317e 100644
> --- a/drivers/c
t;
> I'm likely to publish this new series tomorrow after my tests on a Micron
> memory.
Excellent, please keep me on Cc as I'm already warming up my Spansion part ;-)
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
On Wednesday, September 09, 2015 at 03:24:11 PM, Cyrille Pitchen wrote:
> When their quad or dual I/O mode is enabled, Micron and Macronix spi-nor
> memories don't reply to the regular Read ID (0x9f) command. Instead they
> reply to a new dedicated command Read ID Multiple I/O (0xaf).
>
> If the R
On Wednesday, October 14, 2015 at 05:01:45 PM, Arnd Bergmann wrote:
> On Saturday 19 September 2015 06:42:21 Marek Vasut wrote:
> > This change is similar to e001bbae7147b111fe1aa42beaf835635f3c016e
> > ARM: cmpxchg: avoid warnings from macro-ized cmpxchg() implementations
> >
On Wednesday, September 02, 2015 at 07:12:14 PM, Ranjit Abhimanyu Waghmode
wrote:
> Hi Marek,
>
> > -Original Message-
> > From: Marek Vasut [mailto:ma...@denx.de]
> > Sent: Wednesday, August 26, 2015 12:26 PM
> > To: Ranjit Abhimanyu Waghmode
> > Cc:
On Thursday, September 03, 2015 at 03:25:00 PM, Ranjit Abhimanyu Waghmode wrote:
> Hi,
>
> > -Original Message-
> > From: Marek Vasut [mailto:ma...@denx.de]
> > Sent: Thursday, September 03, 2015 12:26 AM
> > To: Ranjit Abhimanyu Waghmode
> > Cc:
if (ret > 0 && !(ret & mask)) {
> + dev_info(nor->dev, "ISSI Block Protection Bits cleared\n");
> + return 0;
Is the dev_info() really needed ?
> + } else {
> + dev_err(nor->dev, "ISSI Block Protection Bits not cleared\n");
> + return -EINVAL;
> + }
> +}
[...]
--
Best regards,
Marek Vasut
l = read_sr(nor);
>>> + if (val < 0)
>>> + return val;
>>> + if (!(val & mask))
>>> + return 0;
>>> +
>>> + write_enable(nor);
>>> +
>>> + write_sr(nor, val & ~mask);
>>> +
>>> + ret = spi_nor_wait_till_ready(nor);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + ret = read_sr(nor);
>>> + if (ret > 0 && !(ret & mask)) {
>>> + dev_info(nor->dev, "ISSI Block Protection Bits cleared\n");
>>> + return 0;
>>
>> Is the dev_info() really needed ?
>
> Nope. I'll spin a v2 pending the above discussion.
>
>>> + } else {
>>> + dev_err(nor->dev, "ISSI Block Protection Bits not cleared\n");
>>> + return -EINVAL;
>>> + }
>>> +}
>>
>> [...]
>
> Thanks!
--
Best regards,
Marek Vasut
* issi_unlock() - clear BP[0123] write-protection.
>>>>> + * @nor: pointer to a 'struct spi_nor'
>>>>> + *
>>>>> + * Bits [2345] of the Status Register are BP[0123].
>>>>> + * ISSI chips use a different block protection scheme than other
>>>>> chips.
>>>>> + * Just disable the write-protect unilaterally.
>>>>> + *
>>>>> + * Return: 0 on success, -errno otherwise.
>>>>> + */
>>>>> +static int issi_unlock(struct spi_nor *nor)
>>>>> +{
>>>>> + int ret, val;
>>>>> + u8 mask = SR_BP0 | SR_BP1 | SR_BP2 | SR_BP3;
>>>>> +
>>>>> + val = read_sr(nor);
>>>>> + if (val < 0)
>>>>> + return val;
>>>>> + if (!(val & mask))
>>>>> + return 0;
>>>>> +
>>>>> + write_enable(nor);
>>>>> +
>>>>> + write_sr(nor, val & ~mask);
>>>>> +
>>>>> + ret = spi_nor_wait_till_ready(nor);
>>>>> + if (ret)
>>>>> + return ret;
>>>>> +
>>>>> + ret = read_sr(nor);
>>>>> + if (ret > 0 && !(ret & mask)) {
>>>>> + dev_info(nor->dev, "ISSI Block Protection Bits cleared\n");
>>>>> + return 0;
>>>>
>>>> Is the dev_info() really needed ?
>>>
>>> Nope. I'll spin a v2 pending the above discussion.
>>>
>>>>> + } else {
>>>>> + dev_err(nor->dev, "ISSI Block Protection Bits not
>>>>> cleared\n");
>>>>> + return -EINVAL;
>>>>> + }
>>>>> +}
>>>>
>>>> [...]
>>>
>>> Thanks!
--
Best regards,
Marek Vasut
On 06/20/2018 07:27 AM, Richard Weinberger wrote:
> Marek,
>
> Am Mittwoch, 20. Juni 2018, 06:52:09 CEST schrieb Marek Vasut:
>> On 06/19/2018 02:07 PM, Richard Weinberger wrote:
>>> The denali NAND flash controller needs at least two clocks to operate,
>>> n
le = "samtec,vining", "altr,socfpga-cyclone5", "altr,socfpga";
>
> chosen {
> - bootargs = "console=ttyS0,115200";
> + bootargs = "earlyprintk";
Why this earlyprintk ?
> + stdout-path = "serial0:115200n8";
> };
>
> memory@0 {
>
--
Best regards,
Marek Vasut
On 08/08/2018 02:02 PM, Simon Goldschmidt wrote:
> On Wed, Aug 8, 2018 at 1:32 PM Marek Vasut wrote:
>>
>> On 08/08/2018 11:09 AM, Simon Goldschmidt wrote:
>>> Use stdout-path dts property for kernel console.
>>>
>>> There were two socfpga boards le
mcr p15, 0, r0, c1, c0, 1
> +#endif
> __v7_ca17mp_setup:
> - mov r10, #0
> +2: mov r10, #0
> 1: adr r0, __v7_setup_stack_ptr
> ldr r12, [r0]
> add r12, r12, r0@ the local stack
>
--
Best regards,
Marek Vasut
On 08/11/2018 03:58 PM, Marek Vasut wrote:
> On 06/08/2018 12:58 AM, Florian Fainelli wrote:
>> Per the ARM reference manual for the Cortex-A15, The ACTLR:
>>
>> Is a read/write register.
>>
>> Common to the Secure and Non-secure states.
>>
>> Is on
h->digest = alg->digest;
> + hash->export = alg->export;
> + hash->import = alg->import;
>
> if (alg->setkey) {
> hash->setkey = alg->setkey;
> hash->has_setkey = true;
> }
> - if (alg->export)
> - hash->export = alg->export;
> - if (alg->import)
> - hash->import = alg->import;
>
> return 0;
> }
>
--
Best regards,
Marek Vasut
On 01/19/2018 10:53 AM, Kamil Konieczny wrote:
> On 18.01.2018 22:31, Marek Vasut wrote:
>> On 01/18/2018 07:34 PM, Kamil Konieczny wrote:
>>> Export and import are mandatory in async hash. As drivers were
>>> rewritten, drop empty wrappers and correct init of ahash tr
static struct ahash_alg dcp_sha256_alg = {
> .final = dcp_sha_final,
> .finup = dcp_sha_finup,
> .digest = dcp_sha_digest,
> + .import = dcp_sha_noimport,
> + .export = dcp_sha_noexport,
> .halg = {
> .digestsize = SHA256_DIGEST_SIZE,
> .base = {
>
--
Best regards,
Marek Vasut
egister */
> +#define SPINOR_OP_RDXA 0xc8/* Read Extended Address
> Register */
> +#define SPINOR_OP_WRXA 0xc5/* Write Extended Address
> Register */
>
> /* 4-byte address opcodes - used on Spansion and some Macronix flashes. */
> #define SPINOR_OP_READ_4B0x13/* Read data bytes (low frequency) */
>
--
Best regards,
Marek Vasut
On 04/11/2018 05:17 PM, Thor Thayer wrote:
> Hi. Any comments on this patch?
None other than
Reviewed-by: Marek Vasut
sorry for the delay.
btw stop top-posting please.
> On 03/26/2018 09:12 AM, thor.tha...@linux.intel.com wrote:
>> From: Thor Thayer
>>
>> The cur
1 - 100 of 910 matches
Mail list logo
