[PATCH 1/6] SPI: S3C64XX: Rename s3c64xx_spi_cntrlr_info

[PATCH 1/6] SPI: S3C64XX: Rename s3c64xx_spi_cntrlr_info

[jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w]

From: Jassi Brar <jassi.brar-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>

Rename 'struct s3c64xx_spi_cntrlr_info' to lesser wordy
'struct s3c64xx_spi_info'

Signed-off-by: Jassi Brar <jassi.brar-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
---
 drivers/spi/spi_s3c64xx.c |   24 ++++++++++++------------
 1 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/spi/spi_s3c64xx.c b/drivers/spi/spi_s3c64xx.c
index 88a456d..ad93d5d 100644
--- a/drivers/spi/spi_s3c64xx.c
+++ b/drivers/spi/spi_s3c64xx.c
@@ -160,7 +160,7 @@ struct s3c64xx_spi_driver_data {
 	struct platform_device          *pdev;
 	struct spi_master               *master;
 	struct workqueue_struct	        *workqueue;
-	struct s3c64xx_spi_cntrlr_info  *cntrlr_info;
+	struct s3c64xx_spi_info  *cntrlr_info;
 	struct spi_device               *tgl_spi;
 	struct work_struct              work;
 	struct list_head                queue;
@@ -180,7 +180,7 @@ static struct s3c2410_dma_client s3c64xx_spi_dma_client = {
 
 static void flush_fifo(struct s3c64xx_spi_driver_data *sdd)
 {
-	struct s3c64xx_spi_cntrlr_info *sci = sdd->cntrlr_info;
+	struct s3c64xx_spi_info *sci = sdd->cntrlr_info;
 	void __iomem *regs = sdd->regs;
 	unsigned long loops;
 	u32 val;
@@ -225,7 +225,7 @@ static void enable_datapath(struct s3c64xx_spi_driver_data *sdd,
 				struct spi_device *spi,
 				struct spi_transfer *xfer, int dma_mode)
 {
-	struct s3c64xx_spi_cntrlr_info *sci = sdd->cntrlr_info;
+	struct s3c64xx_spi_info *sci = sdd->cntrlr_info;
 	void __iomem *regs = sdd->regs;
 	u32 modecfg, chcfg;
 
@@ -310,7 +310,7 @@ static inline void enable_cs(struct s3c64xx_spi_driver_data *sdd,
 static int wait_for_xfer(struct s3c64xx_spi_driver_data *sdd,
 				struct spi_transfer *xfer, int dma_mode)
 {
-	struct s3c64xx_spi_cntrlr_info *sci = sdd->cntrlr_info;
+	struct s3c64xx_spi_info *sci = sdd->cntrlr_info;
 	void __iomem *regs = sdd->regs;
 	unsigned long val;
 	int ms;
@@ -389,7 +389,7 @@ static inline void disable_cs(struct s3c64xx_spi_driver_data *sdd,
 
 static void s3c64xx_spi_config(struct s3c64xx_spi_driver_data *sdd)
 {
-	struct s3c64xx_spi_cntrlr_info *sci = sdd->cntrlr_info;
+	struct s3c64xx_spi_info *sci = sdd->cntrlr_info;
 	void __iomem *regs = sdd->regs;
 	u32 val;
 
@@ -558,7 +558,7 @@ static void s3c64xx_spi_unmap_mssg(struct s3c64xx_spi_driver_data *sdd,
 static void handle_msg(struct s3c64xx_spi_driver_data *sdd,
 					struct spi_message *msg)
 {
-	struct s3c64xx_spi_cntrlr_info *sci = sdd->cntrlr_info;
+	struct s3c64xx_spi_info *sci = sdd->cntrlr_info;
 	struct spi_device *spi = msg->spi;
 	struct s3c64xx_spi_csinfo *cs = spi->controller_data;
 	struct spi_transfer *xfer;
@@ -786,7 +786,7 @@ static int s3c64xx_spi_setup(struct spi_device *spi)
 {
 	struct s3c64xx_spi_csinfo *cs = spi->controller_data;
 	struct s3c64xx_spi_driver_data *sdd;
-	struct s3c64xx_spi_cntrlr_info *sci;
+	struct s3c64xx_spi_info *sci;
 	struct spi_message *msg;
 	u32 psr, speed;
 	unsigned long flags;
@@ -867,7 +867,7 @@ setup_exit:
 
 static void s3c64xx_spi_hwinit(struct s3c64xx_spi_driver_data *sdd, int channel)
 {
-	struct s3c64xx_spi_cntrlr_info *sci = sdd->cntrlr_info;
+	struct s3c64xx_spi_info *sci = sdd->cntrlr_info;
 	void __iomem *regs = sdd->regs;
 	unsigned int val;
 
@@ -902,7 +902,7 @@ static int __init s3c64xx_spi_probe(struct platform_device *pdev)
 {
 	struct resource	*mem_res, *dmatx_res, *dmarx_res;
 	struct s3c64xx_spi_driver_data *sdd;
-	struct s3c64xx_spi_cntrlr_info *sci;
+	struct s3c64xx_spi_info *sci;
 	struct spi_master *master;
 	int ret;
 
@@ -1078,7 +1078,7 @@ static int s3c64xx_spi_remove(struct platform_device *pdev)
 {
 	struct spi_master *master = spi_master_get(platform_get_drvdata(pdev));
 	struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
-	struct s3c64xx_spi_cntrlr_info *sci = sdd->cntrlr_info;
+	struct s3c64xx_spi_info *sci = sdd->cntrlr_info;
 	struct resource	*mem_res;
 	unsigned long flags;
 
@@ -1118,7 +1118,7 @@ static int s3c64xx_spi_suspend(struct platform_device *pdev, pm_message_t state)
 {
 	struct spi_master *master = spi_master_get(platform_get_drvdata(pdev));
 	struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
-	struct s3c64xx_spi_cntrlr_info *sci = sdd->cntrlr_info;
+	struct s3c64xx_spi_info *sci = sdd->cntrlr_info;
 	struct s3c64xx_spi_csinfo *cs;
 	unsigned long flags;
 
@@ -1144,7 +1144,7 @@ static int s3c64xx_spi_resume(struct platform_device *pdev)
 {
 	struct spi_master *master = spi_master_get(platform_get_drvdata(pdev));
 	struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
-	struct s3c64xx_spi_cntrlr_info *sci = sdd->cntrlr_info;
+	struct s3c64xx_spi_info *sci = sdd->cntrlr_info;
 	unsigned long flags;
 
 	sci->cfg_gpio(pdev);
-- 
1.6.2.5


------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev

[PATCH 2/6] SPI: S3C64XX: Differentiate ip and rate clock

[jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w]

From: Jassi Brar <jassi.brar-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>

The instance of SPI clock for controller and that used for generating
signals ought to be independently handled.

Signed-off-by: Jassi Brar <jassi.brar-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
---
 drivers/spi/spi_s3c64xx.c |   28 ++++++++--------------------
 1 files changed, 8 insertions(+), 20 deletions(-)

diff --git a/drivers/spi/spi_s3c64xx.c b/drivers/spi/spi_s3c64xx.c
index ad93d5d..6d03d8f 100644
--- a/drivers/spi/spi_s3c64xx.c
+++ b/drivers/spi/spi_s3c64xx.c
@@ -1000,10 +1000,7 @@ static int __init s3c64xx_spi_probe(struct platform_device *pdev)
 		goto err4;
 	}
 
-	if (sci->src_clk_nr == S3C64XX_SPI_SRCCLK_PCLK)
-		sci->src_clk = sdd->clk;
-	else
-		sci->src_clk = clk_get(&pdev->dev, sci->src_clk_name);
+	sci->src_clk = clk_get(&pdev->dev, sci->src_clk_name);
 	if (IS_ERR(sci->src_clk)) {
 		dev_err(&pdev->dev,
 			"Unable to acquire clock '%s'\n", sci->src_clk_name);
@@ -1011,7 +1008,7 @@ static int __init s3c64xx_spi_probe(struct platform_device *pdev)
 		goto err5;
 	}
 
-	if (sci->src_clk != sdd->clk && clk_enable(sci->src_clk)) {
+	if (clk_enable(sci->src_clk)) {
 		dev_err(&pdev->dev, "Couldn't enable clock '%s'\n",
 							sci->src_clk_name);
 		ret = -EBUSY;
@@ -1053,11 +1050,9 @@ static int __init s3c64xx_spi_probe(struct platform_device *pdev)
 err8:
 	destroy_workqueue(sdd->workqueue);
 err7:
-	if (sci->src_clk != sdd->clk)
-		clk_disable(sci->src_clk);
+	clk_disable(sci->src_clk);
 err6:
-	if (sci->src_clk != sdd->clk)
-		clk_put(sci->src_clk);
+	clk_put(sci->src_clk);
 err5:
 	clk_disable(sdd->clk);
 err4:
@@ -1093,11 +1088,8 @@ static int s3c64xx_spi_remove(struct platform_device *pdev)
 
 	destroy_workqueue(sdd->workqueue);
 
-	if (sci->src_clk != sdd->clk)
-		clk_disable(sci->src_clk);
-
-	if (sci->src_clk != sdd->clk)
-		clk_put(sci->src_clk);
+	clk_disable(sci->src_clk);
+	clk_put(sci->src_clk);
 
 	clk_disable(sdd->clk);
 	clk_put(sdd->clk);
@@ -1130,9 +1122,7 @@ static int s3c64xx_spi_suspend(struct platform_device *pdev, pm_message_t state)
 		msleep(10);
 
 	/* Disable the clock */
-	if (sci->src_clk != sdd->clk)
-		clk_disable(sci->src_clk);
-
+	clk_disable(sci->src_clk);
 	clk_disable(sdd->clk);
 
 	sdd->cur_speed = 0; /* Output Clock is stopped */
@@ -1150,9 +1140,7 @@ static int s3c64xx_spi_resume(struct platform_device *pdev)
 	sci->cfg_gpio(pdev);
 
 	/* Enable the clock */
-	if (sci->src_clk != sdd->clk)
-		clk_enable(sci->src_clk);
-
+	clk_enable(sci->src_clk);
 	clk_enable(sdd->clk);
 
 	s3c64xx_spi_hwinit(sdd, pdev->id);
-- 
1.6.2.5


------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev

[PATCH 3/6] SPI: S3C64XX: Move src_clk to local driver data

[jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w]

From: Jassi Brar <jassi.brar-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>

The pointer to SPI rate source clock had better be the member of
driver local data structure rather than platform specific.
Also, remove definitions of variable 'sci' that are rendered
useless as a consequence.

Signed-off-by: Jassi Brar <jassi.brar-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
---
 drivers/spi/spi_s3c64xx.c |   36 +++++++++++++++++-------------------
 1 files changed, 17 insertions(+), 19 deletions(-)

diff --git a/drivers/spi/spi_s3c64xx.c b/drivers/spi/spi_s3c64xx.c
index 6d03d8f..3acf381 100644
--- a/drivers/spi/spi_s3c64xx.c
+++ b/drivers/spi/spi_s3c64xx.c
@@ -137,6 +137,7 @@
 /**
  * struct s3c64xx_spi_driver_data - Runtime info holder for SPI driver.
  * @clk: Pointer to the spi clock.
+ * @src_clk: Pointer to the clock used to generate SPI signals.
  * @master: Pointer to the SPI Protocol master.
  * @workqueue: Work queue for the SPI xfer requests.
  * @cntrlr_info: Platform specific data for the controller this driver manages.
@@ -157,6 +158,7 @@
 struct s3c64xx_spi_driver_data {
 	void __iomem                    *regs;
 	struct clk                      *clk;
+	struct clk                      *src_clk;
 	struct platform_device          *pdev;
 	struct spi_master               *master;
 	struct workqueue_struct	        *workqueue;
@@ -389,7 +391,6 @@ static inline void disable_cs(struct s3c64xx_spi_driver_data *sdd,
 
 static void s3c64xx_spi_config(struct s3c64xx_spi_driver_data *sdd)
 {
-	struct s3c64xx_spi_info *sci = sdd->cntrlr_info;
 	void __iomem *regs = sdd->regs;
 	u32 val;
 
@@ -435,7 +436,7 @@ static void s3c64xx_spi_config(struct s3c64xx_spi_driver_data *sdd)
 	/* Configure Clock */
 	val = readl(regs + S3C64XX_SPI_CLK_CFG);
 	val &= ~S3C64XX_SPI_PSR_MASK;
-	val |= ((clk_get_rate(sci->src_clk) / sdd->cur_speed / 2 - 1)
+	val |= ((clk_get_rate(sdd->src_clk) / sdd->cur_speed / 2 - 1)
 			& S3C64XX_SPI_PSR_MASK);
 	writel(val, regs + S3C64XX_SPI_CLK_CFG);
 
@@ -831,17 +832,17 @@ static int s3c64xx_spi_setup(struct spi_device *spi)
 	}
 
 	/* Check if we can provide the requested rate */
-	speed = clk_get_rate(sci->src_clk) / 2 / (0 + 1); /* Max possible */
+	speed = clk_get_rate(sdd->src_clk) / 2 / (0 + 1); /* Max possible */
 
 	if (spi->max_speed_hz > speed)
 		spi->max_speed_hz = speed;
 
-	psr = clk_get_rate(sci->src_clk) / 2 / spi->max_speed_hz - 1;
+	psr = clk_get_rate(sdd->src_clk) / 2 / spi->max_speed_hz - 1;
 	psr &= S3C64XX_SPI_PSR_MASK;
 	if (psr == S3C64XX_SPI_PSR_MASK)
 		psr--;
 
-	speed = clk_get_rate(sci->src_clk) / 2 / (psr + 1);
+	speed = clk_get_rate(sdd->src_clk) / 2 / (psr + 1);
 	if (spi->max_speed_hz < speed) {
 		if (psr+1 < S3C64XX_SPI_PSR_MASK) {
 			psr++;
@@ -851,7 +852,7 @@ static int s3c64xx_spi_setup(struct spi_device *spi)
 		}
 	}
 
-	speed = clk_get_rate(sci->src_clk) / 2 / (psr + 1);
+	speed = clk_get_rate(sdd->src_clk) / 2 / (psr + 1);
 	if (spi->max_speed_hz >= speed)
 		spi->max_speed_hz = speed;
 	else
@@ -1000,15 +1001,15 @@ static int __init s3c64xx_spi_probe(struct platform_device *pdev)
 		goto err4;
 	}
 
-	sci->src_clk = clk_get(&pdev->dev, sci->src_clk_name);
-	if (IS_ERR(sci->src_clk)) {
+	sdd->src_clk = clk_get(&pdev->dev, sci->src_clk_name);
+	if (IS_ERR(sdd->src_clk)) {
 		dev_err(&pdev->dev,
 			"Unable to acquire clock '%s'\n", sci->src_clk_name);
-		ret = PTR_ERR(sci->src_clk);
+		ret = PTR_ERR(sdd->src_clk);
 		goto err5;
 	}
 
-	if (clk_enable(sci->src_clk)) {
+	if (clk_enable(sdd->src_clk)) {
 		dev_err(&pdev->dev, "Couldn't enable clock '%s'\n",
 							sci->src_clk_name);
 		ret = -EBUSY;
@@ -1050,9 +1051,9 @@ static int __init s3c64xx_spi_probe(struct platform_device *pdev)
 err8:
 	destroy_workqueue(sdd->workqueue);
 err7:
-	clk_disable(sci->src_clk);
+	clk_disable(sdd->src_clk);
 err6:
-	clk_put(sci->src_clk);
+	clk_put(sdd->src_clk);
 err5:
 	clk_disable(sdd->clk);
 err4:
@@ -1073,7 +1074,6 @@ static int s3c64xx_spi_remove(struct platform_device *pdev)
 {
 	struct spi_master *master = spi_master_get(platform_get_drvdata(pdev));
 	struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
-	struct s3c64xx_spi_info *sci = sdd->cntrlr_info;
 	struct resource	*mem_res;
 	unsigned long flags;
 
@@ -1088,8 +1088,8 @@ static int s3c64xx_spi_remove(struct platform_device *pdev)
 
 	destroy_workqueue(sdd->workqueue);
 
-	clk_disable(sci->src_clk);
-	clk_put(sci->src_clk);
+	clk_disable(sdd->src_clk);
+	clk_put(sdd->src_clk);
 
 	clk_disable(sdd->clk);
 	clk_put(sdd->clk);
@@ -1110,8 +1110,6 @@ static int s3c64xx_spi_suspend(struct platform_device *pdev, pm_message_t state)
 {
 	struct spi_master *master = spi_master_get(platform_get_drvdata(pdev));
 	struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
-	struct s3c64xx_spi_info *sci = sdd->cntrlr_info;
-	struct s3c64xx_spi_csinfo *cs;
 	unsigned long flags;
 
 	spin_lock_irqsave(&sdd->lock, flags);
@@ -1122,7 +1120,7 @@ static int s3c64xx_spi_suspend(struct platform_device *pdev, pm_message_t state)
 		msleep(10);
 
 	/* Disable the clock */
-	clk_disable(sci->src_clk);
+	clk_disable(sdd->src_clk);
 	clk_disable(sdd->clk);
 
 	sdd->cur_speed = 0; /* Output Clock is stopped */
@@ -1140,7 +1138,7 @@ static int s3c64xx_spi_resume(struct platform_device *pdev)
 	sci->cfg_gpio(pdev);
 
 	/* Enable the clock */
-	clk_enable(sci->src_clk);
+	clk_enable(sdd->src_clk);
 	clk_enable(sdd->clk);
 
 	s3c64xx_spi_hwinit(sdd, pdev->id);
-- 
1.6.2.5


------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev

[PATCH 4/6] SPI: S3C64XX: Check before mem-region release

[jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w]

From: Jassi Brar <jassi.brar-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>

Add precautionary check before releasing memory region.

Signed-off-by: Jassi Brar <jassi.brar-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
---
 drivers/spi/spi_s3c64xx.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/spi/spi_s3c64xx.c b/drivers/spi/spi_s3c64xx.c
index 3acf381..0e883f9 100644
--- a/drivers/spi/spi_s3c64xx.c
+++ b/drivers/spi/spi_s3c64xx.c
@@ -1097,7 +1097,8 @@ static int s3c64xx_spi_remove(struct platform_device *pdev)
 	iounmap((void *) sdd->regs);
 
 	mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	release_mem_region(mem_res->start, resource_size(mem_res));
+	if (mem_res != NULL)
+		release_mem_region(mem_res->start, resource_size(mem_res));
 
 	platform_set_drvdata(pdev, NULL);
 	spi_master_put(master);
-- 
1.6.2.5


------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev

[PATCH 5/6] SPI: S3C64XX: Include moved header

[jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w]

From: Jassi Brar <jassi.brar-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>

Header for platform specific stuff has been rename to include the SoC
type. Include the new header instead.

Signed-off-by: Jassi Brar <jassi.brar-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
---
 drivers/spi/spi_s3c64xx.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/spi/spi_s3c64xx.c b/drivers/spi/spi_s3c64xx.c
index 0e883f9..9fa0b99 100644
--- a/drivers/spi/spi_s3c64xx.c
+++ b/drivers/spi/spi_s3c64xx.c
@@ -28,7 +28,7 @@
 #include <linux/spi/spi.h>
 
 #include <mach/dma.h>
-#include <plat/spi.h>
+#include <plat/s3c64xx-spi.h>
 
 /* Registers and bit-fields */
 
-- 
1.6.2.5


------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev

[PATCH 6/6] SPI: S3C64XX: Add new parameter to cs callback

[jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w]

From: Jassi Brar <jassi.brar-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>

Since most of the chip-selects are simply going to be like
gpio_set_value, it would do good to have the same callback type
so that it could simply be made to point at gpio_set_value.

Signed-off-by: Jassi Brar <jassi.brar-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
---
 drivers/spi/spi_s3c64xx.c |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/spi_s3c64xx.c b/drivers/spi/spi_s3c64xx.c
index 9fa0b99..32db695 100644
--- a/drivers/spi/spi_s3c64xx.c
+++ b/drivers/spi/spi_s3c64xx.c
@@ -300,13 +300,14 @@ static inline void enable_cs(struct s3c64xx_spi_driver_data *sdd,
 		if (sdd->tgl_spi != spi) { /* if last mssg on diff device */
 			/* Deselect the last toggled device */
 			cs = sdd->tgl_spi->controller_data;
-			cs->set_level(spi->mode & SPI_CS_HIGH ? 0 : 1);
+			cs->set_level(cs->line,
+					spi->mode & SPI_CS_HIGH ? 0 : 1);
 		}
 		sdd->tgl_spi = NULL;
 	}
 
 	cs = spi->controller_data;
-	cs->set_level(spi->mode & SPI_CS_HIGH ? 1 : 0);
+	cs->set_level(cs->line, spi->mode & SPI_CS_HIGH ? 1 : 0);
 }
 
 static int wait_for_xfer(struct s3c64xx_spi_driver_data *sdd,
@@ -386,7 +387,7 @@ static inline void disable_cs(struct s3c64xx_spi_driver_data *sdd,
 	if (sdd->tgl_spi == spi)
 		sdd->tgl_spi = NULL;
 
-	cs->set_level(spi->mode & SPI_CS_HIGH ? 0 : 1);
+	cs->set_level(cs->line, spi->mode & SPI_CS_HIGH ? 0 : 1);
 }
 
 static void s3c64xx_spi_config(struct s3c64xx_spi_driver_data *sdd)
-- 
1.6.2.5


------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev

Re: [PATCH 6/6] SPI: S3C64XX: Add new parameter to cs callback

[Grant Likely]

On Mon, Jan 18, 2010 at 2:50 AM,  <jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> From: Jassi Brar <jassi.brar-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>
> Since most of the chip-selects are simply going to be like
> gpio_set_value, it would do good to have the same callback type
> so that it could simply be made to point at gpio_set_value.
>
> Signed-off-by: Jassi Brar <jassi.brar-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>

This patch changes the calling arguments, but I don't see any function
signatures changed to reflect the new parameters.  Is this going to
break stuff?

g.

> ---
>  drivers/spi/spi_s3c64xx.c |    7 ++++---
>  1 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/spi/spi_s3c64xx.c b/drivers/spi/spi_s3c64xx.c
> index 9fa0b99..32db695 100644
> --- a/drivers/spi/spi_s3c64xx.c
> +++ b/drivers/spi/spi_s3c64xx.c
> @@ -300,13 +300,14 @@ static inline void enable_cs(struct s3c64xx_spi_driver_data *sdd,
>                if (sdd->tgl_spi != spi) { /* if last mssg on diff device */
>                        /* Deselect the last toggled device */
>                        cs = sdd->tgl_spi->controller_data;
> -                       cs->set_level(spi->mode & SPI_CS_HIGH ? 0 : 1);
> +                       cs->set_level(cs->line,
> +                                       spi->mode & SPI_CS_HIGH ? 0 : 1);
>                }
>                sdd->tgl_spi = NULL;
>        }
>
>        cs = spi->controller_data;
> -       cs->set_level(spi->mode & SPI_CS_HIGH ? 1 : 0);
> +       cs->set_level(cs->line, spi->mode & SPI_CS_HIGH ? 1 : 0);
>  }
>
>  static int wait_for_xfer(struct s3c64xx_spi_driver_data *sdd,
> @@ -386,7 +387,7 @@ static inline void disable_cs(struct s3c64xx_spi_driver_data *sdd,
>        if (sdd->tgl_spi == spi)
>                sdd->tgl_spi = NULL;
>
> -       cs->set_level(spi->mode & SPI_CS_HIGH ? 0 : 1);
> +       cs->set_level(cs->line, spi->mode & SPI_CS_HIGH ? 0 : 1);
>  }
>
>  static void s3c64xx_spi_config(struct s3c64xx_spi_driver_data *sdd)
> --
> 1.6.2.5
>
>



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev

Re: [PATCH 6/6] SPI: S3C64XX: Add new parameter to cs callback

[jassi brar]

On Tue, Jan 19, 2010 at 3:15 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Mon, Jan 18, 2010 at 2:50 AM,  <jassisinghbrar@gmail.com> wrote:
>> From: Jassi Brar <jassi.brar@samsung.com>
>>
>> Since most of the chip-selects are simply going to be like
>> gpio_set_value, it would do good to have the same callback type
>> so that it could simply be made to point at gpio_set_value.
>>
>> Signed-off-by: Jassi Brar <jassi.brar@samsung.com>
>
> This patch changes the calling arguments, but I don't see any function
> signatures changed to reflect the new parameters.  Is this going to
> break stuff?
I hope replies to your other queries will make this clear too.

In summary, only drivers/spi/spi_s3c64xx.c was pulled in your tree while
the backend platform support for this SPI driver was held back until
some changes were made.
These 6 patches update the driver for those changes suggested by my
SoC support maintainer(Ben Dooks).
I think you could simply apply these patches, because the extant driver
is useless without platform support (which has only been accepted yesterday.)

> g.
>
>> ---
>>  drivers/spi/spi_s3c64xx.c |    7 ++++---
>>  1 files changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/spi/spi_s3c64xx.c b/drivers/spi/spi_s3c64xx.c
>> index 9fa0b99..32db695 100644
>> --- a/drivers/spi/spi_s3c64xx.c
>> +++ b/drivers/spi/spi_s3c64xx.c
>> @@ -300,13 +300,14 @@ static inline void enable_cs(struct s3c64xx_spi_driver_data *sdd,
>>                if (sdd->tgl_spi != spi) { /* if last mssg on diff device */
>>                        /* Deselect the last toggled device */
>>                        cs = sdd->tgl_spi->controller_data;
>> -                       cs->set_level(spi->mode & SPI_CS_HIGH ? 0 : 1);
>> +                       cs->set_level(cs->line,
>> +                                       spi->mode & SPI_CS_HIGH ? 0 : 1);
>>                }
>>                sdd->tgl_spi = NULL;
>>        }
>>
>>        cs = spi->controller_data;
>> -       cs->set_level(spi->mode & SPI_CS_HIGH ? 1 : 0);
>> +       cs->set_level(cs->line, spi->mode & SPI_CS_HIGH ? 1 : 0);
>>  }
>>
>>  static int wait_for_xfer(struct s3c64xx_spi_driver_data *sdd,
>> @@ -386,7 +387,7 @@ static inline void disable_cs(struct s3c64xx_spi_driver_data *sdd,
>>        if (sdd->tgl_spi == spi)
>>                sdd->tgl_spi = NULL;
>>
>> -       cs->set_level(spi->mode & SPI_CS_HIGH ? 0 : 1);
>> +       cs->set_level(cs->line, spi->mode & SPI_CS_HIGH ? 0 : 1);
>>  }
>>
>>  static void s3c64xx_spi_config(struct s3c64xx_spi_driver_data *sdd)
>> --
>> 1.6.2.5
>>
>>
>
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH 5/6] SPI: S3C64XX: Include moved header

[Grant Likely]

On Mon, Jan 18, 2010 at 2:50 AM,  <jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> From: Jassi Brar <jassi.brar-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>
> Header for platform specific stuff has been rename to include the SoC
> type. Include the new header instead.

Is this to fix a compile failure?  If so, then you should say so in
the subject so I know that it is higher priority to pick up.

g.

>
> Signed-off-by: Jassi Brar <jassi.brar-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> ---
>  drivers/spi/spi_s3c64xx.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/spi/spi_s3c64xx.c b/drivers/spi/spi_s3c64xx.c
> index 0e883f9..9fa0b99 100644
> --- a/drivers/spi/spi_s3c64xx.c
> +++ b/drivers/spi/spi_s3c64xx.c
> @@ -28,7 +28,7 @@
>  #include <linux/spi/spi.h>
>
>  #include <mach/dma.h>
> -#include <plat/spi.h>
> +#include <plat/s3c64xx-spi.h>
>
>  /* Registers and bit-fields */
>
> --
> 1.6.2.5
>
>



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev

Re: [PATCH 5/6] SPI: S3C64XX: Include moved header

[jassi brar]

On Tue, Jan 19, 2010 at 3:13 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Mon, Jan 18, 2010 at 2:50 AM,  <jassisinghbrar@gmail.com> wrote:
>> From: Jassi Brar <jassi.brar@samsung.com>
>>
>> Header for platform specific stuff has been rename to include the SoC
>> type. Include the new header instead.
>
> Is this to fix a compile failure?  If so, then you should say so in
> the subject so I know that it is higher priority to pick up.
As is said in another reply, platform support for SPI driver has only
been accepted yesterday. So, this driver had no use until now.
No compile failure, but some of the definitions has been moved in
the 'background' (old headers were never present anyways)

> g.
>
>>
>> Signed-off-by: Jassi Brar <jassi.brar@samsung.com>
>> ---
>>  drivers/spi/spi_s3c64xx.c |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/spi/spi_s3c64xx.c b/drivers/spi/spi_s3c64xx.c
>> index 0e883f9..9fa0b99 100644
>> --- a/drivers/spi/spi_s3c64xx.c
>> +++ b/drivers/spi/spi_s3c64xx.c
>> @@ -28,7 +28,7 @@
>>  #include <linux/spi/spi.h>
>>
>>  #include <mach/dma.h>
>> -#include <plat/spi.h>
>> +#include <plat/s3c64xx-spi.h>
>>
>>  /* Registers and bit-fields */
>>
>> --
>> 1.6.2.5
>>
>>
>
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH 4/6] SPI: S3C64XX: Check before mem-region release

[Grant Likely]

On Mon, Jan 18, 2010 at 2:50 AM,  <jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> From: Jassi Brar <jassi.brar-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>
> Add precautionary check before releasing memory region.
>
> Signed-off-by: Jassi Brar <jassi.brar-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> ---
>  drivers/spi/spi_s3c64xx.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/spi/spi_s3c64xx.c b/drivers/spi/spi_s3c64xx.c
> index 3acf381..0e883f9 100644
> --- a/drivers/spi/spi_s3c64xx.c
> +++ b/drivers/spi/spi_s3c64xx.c
> @@ -1097,7 +1097,8 @@ static int s3c64xx_spi_remove(struct platform_device *pdev)
>        iounmap((void *) sdd->regs);
>
>        mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> -       release_mem_region(mem_res->start, resource_size(mem_res));
> +       if (mem_res != NULL)
> +               release_mem_region(mem_res->start, resource_size(mem_res));


request_mem_region() in in an unconditional path in the .probe() hook.
 Are you seeing failure on the remove path?

g.

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev

Re: [PATCH 4/6] SPI: S3C64XX: Check before mem-region release

[jassi brar]

On Tue, Jan 19, 2010 at 3:12 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Mon, Jan 18, 2010 at 2:50 AM,  <jassisinghbrar@gmail.com> wrote:
>> From: Jassi Brar <jassi.brar@samsung.com>
>>
>> Add precautionary check before releasing memory region.
>>
>> Signed-off-by: Jassi Brar <jassi.brar@samsung.com>
>> ---
>>  drivers/spi/spi_s3c64xx.c |    3 ++-
>>  1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/spi/spi_s3c64xx.c b/drivers/spi/spi_s3c64xx.c
>> index 3acf381..0e883f9 100644
>> --- a/drivers/spi/spi_s3c64xx.c
>> +++ b/drivers/spi/spi_s3c64xx.c
>> @@ -1097,7 +1097,8 @@ static int s3c64xx_spi_remove(struct platform_device *pdev)
>>        iounmap((void *) sdd->regs);
>>
>>        mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> -       release_mem_region(mem_res->start, resource_size(mem_res));
>> +       if (mem_res != NULL)
>> +               release_mem_region(mem_res->start, resource_size(mem_res));
>
>
> request_mem_region() in in an unconditional path in the .probe() hook.
>  Are you seeing failure on the remove path?
No failure, just warnings upon running some static code analyzer.

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH 4/6] SPI: S3C64XX: Check before mem-region release

[Grant Likely]

On Mon, Jan 18, 2010 at 4:42 PM, jassi brar <jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Tue, Jan 19, 2010 at 3:12 AM, Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote:
>> On Mon, Jan 18, 2010 at 2:50 AM,  <jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> From: Jassi Brar <jassi.brar-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>>>
>>> Add precautionary check before releasing memory region.
>>>
>>> Signed-off-by: Jassi Brar <jassi.brar-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>>> ---
>>>  drivers/spi/spi_s3c64xx.c |    3 ++-
>>>  1 files changed, 2 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/spi/spi_s3c64xx.c b/drivers/spi/spi_s3c64xx.c
>>> index 3acf381..0e883f9 100644
>>> --- a/drivers/spi/spi_s3c64xx.c
>>> +++ b/drivers/spi/spi_s3c64xx.c
>>> @@ -1097,7 +1097,8 @@ static int s3c64xx_spi_remove(struct platform_device *pdev)
>>>        iounmap((void *) sdd->regs);
>>>
>>>        mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> -       release_mem_region(mem_res->start, resource_size(mem_res));
>>> +       if (mem_res != NULL)
>>> +               release_mem_region(mem_res->start, resource_size(mem_res));
>>
>>
>> request_mem_region() in in an unconditional path in the .probe() hook.
>>  Are you seeing failure on the remove path?
> No failure, just warnings upon running some static code analyzer.

Okay.  For future reference, it makes my job easier (and more likely
that I'll pick up the patch) if the commit log states why a change is
being made, and not just what.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev

Re: [PATCH 4/6] SPI: S3C64XX: Check before mem-region release

[jassi brar]

On Tue, Jan 19, 2010 at 11:32 AM, Grant Likely
<grant.likely@secretlab.ca> wrote:
> On Mon, Jan 18, 2010 at 4:42 PM, jassi brar <jassisinghbrar@gmail.com> wrote:
>> On Tue, Jan 19, 2010 at 3:12 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
>>> On Mon, Jan 18, 2010 at 2:50 AM,  <jassisinghbrar@gmail.com> wrote:
>>>> From: Jassi Brar <jassi.brar@samsung.com>
>>>>
>>>> Add precautionary check before releasing memory region.
>>>>
>>>> Signed-off-by: Jassi Brar <jassi.brar@samsung.com>
>>>> ---
>>>>  drivers/spi/spi_s3c64xx.c |    3 ++-
>>>>  1 files changed, 2 insertions(+), 1 deletions(-)
>>>>
>>>> diff --git a/drivers/spi/spi_s3c64xx.c b/drivers/spi/spi_s3c64xx.c
>>>> index 3acf381..0e883f9 100644
>>>> --- a/drivers/spi/spi_s3c64xx.c
>>>> +++ b/drivers/spi/spi_s3c64xx.c
>>>> @@ -1097,7 +1097,8 @@ static int s3c64xx_spi_remove(struct platform_device *pdev)
>>>>        iounmap((void *) sdd->regs);
>>>>
>>>>        mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>>> -       release_mem_region(mem_res->start, resource_size(mem_res));
>>>> +       if (mem_res != NULL)
>>>> +               release_mem_region(mem_res->start, resource_size(mem_res));
>>>
>>>
>>> request_mem_region() in in an unconditional path in the .probe() hook.
>>>  Are you seeing failure on the remove path?
>> No failure, just warnings upon running some static code analyzer.
>
> Okay.  For future reference, it makes my job easier (and more likely
> that I'll pick up the patch) if the commit log states why a change is
> being made, and not just what.
Ok, will take care in future. Thanks.

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH 4/6] SPI: S3C64XX: Check before mem-region release

[jassi brar]

On Tue, Jan 19, 2010 at 6:52 PM, jassi brar <jassisinghbrar@gmail.com> wrote:
> On Tue, Jan 19, 2010 at 11:32 AM, Grant Likely
> <grant.likely@secretlab.ca> wrote:
>> On Mon, Jan 18, 2010 at 4:42 PM, jassi brar <jassisinghbrar@gmail.com> wrote:
>>> On Tue, Jan 19, 2010 at 3:12 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
>>>> On Mon, Jan 18, 2010 at 2:50 AM,  <jassisinghbrar@gmail.com> wrote:
>>>>> From: Jassi Brar <jassi.brar@samsung.com>
>>>>>
>>>>> Add precautionary check before releasing memory region.
>>>>>
>>>>> Signed-off-by: Jassi Brar <jassi.brar@samsung.com>
>>>>> ---
>>>>>  drivers/spi/spi_s3c64xx.c |    3 ++-
>>>>>  1 files changed, 2 insertions(+), 1 deletions(-)
>>>>>
>>>>> diff --git a/drivers/spi/spi_s3c64xx.c b/drivers/spi/spi_s3c64xx.c
>>>>> index 3acf381..0e883f9 100644
>>>>> --- a/drivers/spi/spi_s3c64xx.c
>>>>> +++ b/drivers/spi/spi_s3c64xx.c
>>>>> @@ -1097,7 +1097,8 @@ static int s3c64xx_spi_remove(struct platform_device *pdev)
>>>>>        iounmap((void *) sdd->regs);
>>>>>
>>>>>        mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>>>> -       release_mem_region(mem_res->start, resource_size(mem_res));
>>>>> +       if (mem_res != NULL)
>>>>> +               release_mem_region(mem_res->start, resource_size(mem_res));
>>>>
>>>>
>>>> request_mem_region() in in an unconditional path in the .probe() hook.
>>>>  Are you seeing failure on the remove path?
>>> No failure, just warnings upon running some static code analyzer.
>>
>> Okay.  For future reference, it makes my job easier (and more likely
>> that I'll pick up the patch) if the commit log states why a change is
>> being made, and not just what.
> Ok, will take care in future. Thanks.
Hi Grant Likely,
 You have reviewed this series of patches but didn't ACK/NAK.
Could you kindly confirm if u accept them or want some changes?
Thanks.

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH 4/6] SPI: S3C64XX: Check before mem-region release

[jassi brar]

On Thu, Jan 21, 2010 at 10:35 AM, jassi brar <jassisinghbrar@gmail.com> wrote:
> On Tue, Jan 19, 2010 at 6:52 PM, jassi brar <jassisinghbrar@gmail.com> wrote:
>> On Tue, Jan 19, 2010 at 11:32 AM, Grant Likely
>> <grant.likely@secretlab.ca> wrote:
>>> On Mon, Jan 18, 2010 at 4:42 PM, jassi brar <jassisinghbrar@gmail.com> wrote:
>>>> On Tue, Jan 19, 2010 at 3:12 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
>>>>> On Mon, Jan 18, 2010 at 2:50 AM,  <jassisinghbrar@gmail.com> wrote:
>>>>>> From: Jassi Brar <jassi.brar@samsung.com>
>>>>>>
>>>>>> Add precautionary check before releasing memory region.
>>>>>>
>>>>>> Signed-off-by: Jassi Brar <jassi.brar@samsung.com>
>>>>>> ---
>>>>>>  drivers/spi/spi_s3c64xx.c |    3 ++-
>>>>>>  1 files changed, 2 insertions(+), 1 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/spi/spi_s3c64xx.c b/drivers/spi/spi_s3c64xx.c
>>>>>> index 3acf381..0e883f9 100644
>>>>>> --- a/drivers/spi/spi_s3c64xx.c
>>>>>> +++ b/drivers/spi/spi_s3c64xx.c
>>>>>> @@ -1097,7 +1097,8 @@ static int s3c64xx_spi_remove(struct platform_device *pdev)
>>>>>>        iounmap((void *) sdd->regs);
>>>>>>
>>>>>>        mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>>>>> -       release_mem_region(mem_res->start, resource_size(mem_res));
>>>>>> +       if (mem_res != NULL)
>>>>>> +               release_mem_region(mem_res->start, resource_size(mem_res));
>>>>>
>>>>>
>>>>> request_mem_region() in in an unconditional path in the .probe() hook.
>>>>>  Are you seeing failure on the remove path?
>>>> No failure, just warnings upon running some static code analyzer.
>>>
>>> Okay.  For future reference, it makes my job easier (and more likely
>>> that I'll pick up the patch) if the commit log states why a change is
>>> being made, and not just what.
>> Ok, will take care in future. Thanks.
> Hi Grant Likely,
>  You have reviewed this series of patches but didn't ACK/NAK.
> Could you kindly confirm if u accept them or want some changes?
> Thanks.
Nevermind, I just saw ur ACK at my official ID (many maintainers reply
something like
'pulled now' to the patch thread but thats ok if you ACK personally).
Thanks.

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH 4/6] SPI: S3C64XX: Check before mem-region release

[Grant Likely]

On Wed, Jan 20, 2010 at 6:46 PM, jassi brar <jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Thu, Jan 21, 2010 at 10:35 AM, jassi brar <jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> Hi Grant Likely,
>>  You have reviewed this series of patches but didn't ACK/NAK.
>> Could you kindly confirm if u accept them or want some changes?
>> Thanks.
> Nevermind, I just saw ur ACK at my official ID (many maintainers reply
> something like
> 'pulled now' to the patch thread but thats ok if you ACK personally).
> Thanks.

I'm using patchwork.kernel.org for collecting spi patches.
Unfortunately patchwork doesn't provide any mechanism for emailing
"merged" messages when I accept patches.  To compensate, I've started
cc'ing patch authors my next- branch update message when I push out an
updated tree.

You can also always look at patchwork.kernel.org to see if your
patches are still in the queue.  I won't forget accidentally drop any
patches tracked by patchwork.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev

Re: [PATCH 4/6] SPI: S3C64XX: Check before mem-region release

[jassi brar]

On Thu, Jan 21, 2010 at 11:55 AM, Grant Likely
<grant.likely@secretlab.ca> wrote:
> On Wed, Jan 20, 2010 at 6:46 PM, jassi brar <jassisinghbrar@gmail.com> wrote:
>> On Thu, Jan 21, 2010 at 10:35 AM, jassi brar <jassisinghbrar@gmail.com> wrote:
>>> Hi Grant Likely,
>>>  You have reviewed this series of patches but didn't ACK/NAK.
>>> Could you kindly confirm if u accept them or want some changes?
>>> Thanks.
>> Nevermind, I just saw ur ACK at my official ID (many maintainers reply
>> something like
>> 'pulled now' to the patch thread but thats ok if you ACK personally).
>> Thanks.
>
> I'm using patchwork.kernel.org for collecting spi patches.
> Unfortunately patchwork doesn't provide any mechanism for emailing
> "merged" messages when I accept patches.  To compensate, I've started
> cc'ing patch authors my next- branch update message when I push out an
> updated tree.
>
> You can also always look at patchwork.kernel.org to see if your
> patches are still in the queue.  I won't forget accidentally drop any
> patches tracked by patchwork.
well, it might not just be the submitter, but also others in the thread
interested in knowing the fate of a particular patch. And having to
poll some repo for that, isn't very efficient. It's not important to be notified
_when_ you accept the patch, but only _if_ you accept, which I think
you would know after seeing the patch and/or some further clarifications
from the submitter.
regards.

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH 4/6] SPI: S3C64XX: Check before mem-region release

[Grant Likely]

On Wed, Jan 20, 2010 at 8:06 PM, jassi brar <jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Thu, Jan 21, 2010 at 11:55 AM, Grant Likely
> <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote:
>> On Wed, Jan 20, 2010 at 6:46 PM, jassi brar <jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> On Thu, Jan 21, 2010 at 10:35 AM, jassi brar <jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>> Hi Grant Likely,
>>>>  You have reviewed this series of patches but didn't ACK/NAK.
>>>> Could you kindly confirm if u accept them or want some changes?
>>>> Thanks.
>>> Nevermind, I just saw ur ACK at my official ID (many maintainers reply
>>> something like
>>> 'pulled now' to the patch thread but thats ok if you ACK personally).
>>> Thanks.
>>
>> I'm using patchwork.kernel.org for collecting spi patches.
>> Unfortunately patchwork doesn't provide any mechanism for emailing
>> "merged" messages when I accept patches.  To compensate, I've started
>> cc'ing patch authors my next- branch update message when I push out an
>> updated tree.
>>
>> You can also always look at patchwork.kernel.org to see if your
>> patches are still in the queue.  I won't forget accidentally drop any
>> patches tracked by patchwork.
> well, it might not just be the submitter, but also others in the thread
> interested in knowing the fate of a particular patch. And having to
> poll some repo for that, isn't very efficient. It's not important to be notified
> _when_ you accept the patch, but only _if_ you accept, which I think
> you would know after seeing the patch and/or some further clarifications
> from the submitter.

Since I review patches on patchwork, I don't have an easy link between
what I'm picking up and my email client.  Only when I need to comment
on something will I actually go and find the thread in my mailer.  So
it is considerably less efficient for me to go and reply to every
patch submission.

Jeremy, would it be possible to have a way of sending out a status
update email from within patchwork?

Thanks,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev

Re: [PATCH 4/6] SPI: S3C64XX: Check before mem-region release

[Carl-Daniel Hailfinger]

On 21.01.2010 16:00, Grant Likely wrote:
> On Wed, Jan 20, 2010 at 8:06 PM, jassi brar <jassisinghbrar@gmail.com> wrote:
>   
>> On Thu, Jan 21, 2010 at 11:55 AM, Grant Likely
>> <grant.likely@secretlab.ca> wrote:
>>     
>>> On Wed, Jan 20, 2010 at 6:46 PM, jassi brar <jassisinghbrar@gmail.com> wrote:
>>>       
>>>> On Thu, Jan 21, 2010 at 10:35 AM, jassi brar <jassisinghbrar@gmail.com> wrote:
>>>>         
>>>>> Hi Grant Likely,
>>>>>  You have reviewed this series of patches but didn't ACK/NAK.
>>>>> Could you kindly confirm if u accept them or want some changes?
>>>>> Thanks.
>>>>>           
>>>> Nevermind, I just saw ur ACK at my official ID (many maintainers reply
>>>> something like
>>>> 'pulled now' to the patch thread but thats ok if you ACK personally).
>>>> Thanks.
>>>>         
>>> I'm using patchwork.kernel.org for collecting spi patches.
>>> Unfortunately patchwork doesn't provide any mechanism for emailing
>>> "merged" messages when I accept patches.  To compensate, I've started
>>> cc'ing patch authors my next- branch update message when I push out an
>>> updated tree.
>>>
>>> You can also always look at patchwork.kernel.org to see if your
>>> patches are still in the queue.  I won't forget accidentally drop any
>>> patches tracked by patchwork.
>>>       
>> well, it might not just be the submitter, but also others in the thread
>> interested in knowing the fate of a particular patch. And having to
>> poll some repo for that, isn't very efficient. It's not important to be notified
>> _when_ you accept the patch, but only _if_ you accept, which I think
>> you would know after seeing the patch and/or some further clarifications
>> from the submitter.
>>     
>
> Since I review patches on patchwork, I don't have an easy link between
> what I'm picking up and my email client.  Only when I need to comment
> on something will I actually go and find the thread in my mailer.  So
> it is considerably less efficient for me to go and reply to every
> patch submission.
>
> Jeremy, would it be possible to have a way of sending out a status
> update email from within patchwork?
>   

There is an unfinished Patchwork patch which allows you to click on a
mailto: link at the beginning of the Patchwork page and your mailer will
preserve threading (sort of, the reply will always be to the original
patch, and the list and the submitter will be in CC). Basically, the
mailto: link has In-Reply-To and Subject headers set to correct values.
It might be possible to extend this a bit and get all responders added
to CC.

That patch is unfinished, though, so if you know Python, Patchwork, and
the framework used by Patchwork you can probably beat it into a shape
that is useful for your purposes. If you're interested, I can dig it up.

Regards,
Carl-Daniel

-- 
Developer quote of the year:
"We are juggling too many chainsaws and flaming arrows and tigers."

Re: [PATCH 4/6] SPI: S3C64XX: Check before mem-region release

[Ralf Baechle]

On Thu, Jan 21, 2010 at 08:00:11AM -0700, Grant Likely wrote:

> Since I review patches on patchwork, I don't have an easy link between
> what I'm picking up and my email client.  Only when I need to comment
> on something will I actually go and find the thread in my mailer.  So
> it is considerably less efficient for me to go and reply to every
> patch submission.

I use the message-id: header from the patchwork page to find a patch in
my mailfolder.  That's not too time consuming and has the advantage that
all my mail replies are also in my mail folders.  I'm using mutt; I
know some mail clients mail readers make searching for a message ID a
pain.

  Ralf

Re: [PATCH 2/6] SPI: S3C64XX: Differentiate ip and rate clock

[Grant Likely]

On Mon, Jan 18, 2010 at 2:50 AM,  <jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> From: Jassi Brar <jassi.brar-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>
> The instance of SPI clock for controller and that used for generating
> signals ought to be independently handled.
>
> Signed-off-by: Jassi Brar <jassi.brar-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>

Will this patch break existing users of the driver that depend on the
sci->src_clk checks?

g.

> ---
>  drivers/spi/spi_s3c64xx.c |   28 ++++++++--------------------
>  1 files changed, 8 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/spi/spi_s3c64xx.c b/drivers/spi/spi_s3c64xx.c
> index ad93d5d..6d03d8f 100644
> --- a/drivers/spi/spi_s3c64xx.c
> +++ b/drivers/spi/spi_s3c64xx.c
> @@ -1000,10 +1000,7 @@ static int __init s3c64xx_spi_probe(struct platform_device *pdev)
>                goto err4;
>        }
>
> -       if (sci->src_clk_nr == S3C64XX_SPI_SRCCLK_PCLK)
> -               sci->src_clk = sdd->clk;
> -       else
> -               sci->src_clk = clk_get(&pdev->dev, sci->src_clk_name);
> +       sci->src_clk = clk_get(&pdev->dev, sci->src_clk_name);
>        if (IS_ERR(sci->src_clk)) {
>                dev_err(&pdev->dev,
>                        "Unable to acquire clock '%s'\n", sci->src_clk_name);
> @@ -1011,7 +1008,7 @@ static int __init s3c64xx_spi_probe(struct platform_device *pdev)
>                goto err5;
>        }
>
> -       if (sci->src_clk != sdd->clk && clk_enable(sci->src_clk)) {
> +       if (clk_enable(sci->src_clk)) {
>                dev_err(&pdev->dev, "Couldn't enable clock '%s'\n",
>                                                        sci->src_clk_name);
>                ret = -EBUSY;
> @@ -1053,11 +1050,9 @@ static int __init s3c64xx_spi_probe(struct platform_device *pdev)
>  err8:
>        destroy_workqueue(sdd->workqueue);
>  err7:
> -       if (sci->src_clk != sdd->clk)
> -               clk_disable(sci->src_clk);
> +       clk_disable(sci->src_clk);
>  err6:
> -       if (sci->src_clk != sdd->clk)
> -               clk_put(sci->src_clk);
> +       clk_put(sci->src_clk);
>  err5:
>        clk_disable(sdd->clk);
>  err4:
> @@ -1093,11 +1088,8 @@ static int s3c64xx_spi_remove(struct platform_device *pdev)
>
>        destroy_workqueue(sdd->workqueue);
>
> -       if (sci->src_clk != sdd->clk)
> -               clk_disable(sci->src_clk);
> -
> -       if (sci->src_clk != sdd->clk)
> -               clk_put(sci->src_clk);
> +       clk_disable(sci->src_clk);
> +       clk_put(sci->src_clk);
>
>        clk_disable(sdd->clk);
>        clk_put(sdd->clk);
> @@ -1130,9 +1122,7 @@ static int s3c64xx_spi_suspend(struct platform_device *pdev, pm_message_t state)
>                msleep(10);
>
>        /* Disable the clock */
> -       if (sci->src_clk != sdd->clk)
> -               clk_disable(sci->src_clk);
> -
> +       clk_disable(sci->src_clk);
>        clk_disable(sdd->clk);
>
>        sdd->cur_speed = 0; /* Output Clock is stopped */
> @@ -1150,9 +1140,7 @@ static int s3c64xx_spi_resume(struct platform_device *pdev)
>        sci->cfg_gpio(pdev);
>
>        /* Enable the clock */
> -       if (sci->src_clk != sdd->clk)
> -               clk_enable(sci->src_clk);
> -
> +       clk_enable(sci->src_clk);
>        clk_enable(sdd->clk);
>
>        s3c64xx_spi_hwinit(sdd, pdev->id);
> --
> 1.6.2.5
>
>



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev

Re: [PATCH 2/6] SPI: S3C64XX: Differentiate ip and rate clock

[jassi brar]

On Tue, Jan 19, 2010 at 2:58 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Mon, Jan 18, 2010 at 2:50 AM,  <jassisinghbrar@gmail.com> wrote:
>> From: Jassi Brar <jassi.brar@samsung.com>
>>
>> The instance of SPI clock for controller and that used for generating
>> signals ought to be independently handled.
>>
>> Signed-off-by: Jassi Brar <jassi.brar@samsung.com>
>
> Will this patch break existing users of the driver that depend on the
> sci->src_clk checks?
No, it won't break.
Current driver in the tree can't be used at all since there is no platform stuff
there that is essential for even the probe to be called.

>
> g.
>
>> ---
>>  drivers/spi/spi_s3c64xx.c |   28 ++++++++--------------------
>>  1 files changed, 8 insertions(+), 20 deletions(-)
>>
>> diff --git a/drivers/spi/spi_s3c64xx.c b/drivers/spi/spi_s3c64xx.c
>> index ad93d5d..6d03d8f 100644
>> --- a/drivers/spi/spi_s3c64xx.c
>> +++ b/drivers/spi/spi_s3c64xx.c
>> @@ -1000,10 +1000,7 @@ static int __init s3c64xx_spi_probe(struct platform_device *pdev)
>>                goto err4;
>>        }
>>
>> -       if (sci->src_clk_nr == S3C64XX_SPI_SRCCLK_PCLK)
>> -               sci->src_clk = sdd->clk;
>> -       else
>> -               sci->src_clk = clk_get(&pdev->dev, sci->src_clk_name);
>> +       sci->src_clk = clk_get(&pdev->dev, sci->src_clk_name);
>>        if (IS_ERR(sci->src_clk)) {
>>                dev_err(&pdev->dev,
>>                        "Unable to acquire clock '%s'\n", sci->src_clk_name);
>> @@ -1011,7 +1008,7 @@ static int __init s3c64xx_spi_probe(struct platform_device *pdev)
>>                goto err5;
>>        }
>>
>> -       if (sci->src_clk != sdd->clk && clk_enable(sci->src_clk)) {
>> +       if (clk_enable(sci->src_clk)) {
>>                dev_err(&pdev->dev, "Couldn't enable clock '%s'\n",
>>                                                        sci->src_clk_name);
>>                ret = -EBUSY;
>> @@ -1053,11 +1050,9 @@ static int __init s3c64xx_spi_probe(struct platform_device *pdev)
>>  err8:
>>        destroy_workqueue(sdd->workqueue);
>>  err7:
>> -       if (sci->src_clk != sdd->clk)
>> -               clk_disable(sci->src_clk);
>> +       clk_disable(sci->src_clk);
>>  err6:
>> -       if (sci->src_clk != sdd->clk)
>> -               clk_put(sci->src_clk);
>> +       clk_put(sci->src_clk);
>>  err5:
>>        clk_disable(sdd->clk);
>>  err4:
>> @@ -1093,11 +1088,8 @@ static int s3c64xx_spi_remove(struct platform_device *pdev)
>>
>>        destroy_workqueue(sdd->workqueue);
>>
>> -       if (sci->src_clk != sdd->clk)
>> -               clk_disable(sci->src_clk);
>> -
>> -       if (sci->src_clk != sdd->clk)
>> -               clk_put(sci->src_clk);
>> +       clk_disable(sci->src_clk);
>> +       clk_put(sci->src_clk);
>>
>>        clk_disable(sdd->clk);
>>        clk_put(sdd->clk);
>> @@ -1130,9 +1122,7 @@ static int s3c64xx_spi_suspend(struct platform_device *pdev, pm_message_t state)
>>                msleep(10);
>>
>>        /* Disable the clock */
>> -       if (sci->src_clk != sdd->clk)
>> -               clk_disable(sci->src_clk);
>> -
>> +       clk_disable(sci->src_clk);
>>        clk_disable(sdd->clk);
>>
>>        sdd->cur_speed = 0; /* Output Clock is stopped */
>> @@ -1150,9 +1140,7 @@ static int s3c64xx_spi_resume(struct platform_device *pdev)
>>        sci->cfg_gpio(pdev);
>>
>>        /* Enable the clock */
>> -       if (sci->src_clk != sdd->clk)
>> -               clk_enable(sci->src_clk);
>> -
>> +       clk_enable(sci->src_clk);
>>        clk_enable(sdd->clk);
>>
>>        s3c64xx_spi_hwinit(sdd, pdev->id);
>> --
>> 1.6.2.5
>>
>>
>
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general